[WIP] local config types

[dk1a]

I tried to keep a single mudConfig function for local types, but that seems impossible.
Instead, I separate it into defineConfig and expandConfig, which is basically the approach from #750

plugin definition is easier than globals

Local plugins mostly just need an expandConfig function.

Global plugins need both a global version of an expandConfig function, and a module declaration with interface merging.

Globals could be refactored to be more compact and have good templates, but they'll still be twice as complicated here

config definition is harder than globals

const _typedExpandConfig = expandConfig as ExpandConfig<typeof config>;
type ExpandedConfig = MergeReturnType<typeof _typedExpandConfig<typeof config>>;
export default expandConfig(config) as ExpandedConfig;

• I put this scary config expansion in mud.config.mts (which would be bad ux) mostly to show it all in 1 place
• It could be moved to a template so it's right before setupMUDV2Network (it still remains in userland, but more hidden and unintrusive)
• It can't be moved into setupMUDV2Network because typescript doesn't support higher-kinded types Allow classes to be parametric in other parametric classes microsoft/TypeScript#1213
• something like https://github.com/pelotom/hkts and forcing plugin authors to use placeholder types seems like the worst of all options

Plugin dependencies are harder than globals

It comes down to who has the responsibility for the correct order of plugin dependencies:

• For global plugins it's the plugin author, because importing plugin deps needs to happen only once and further imports are ignored
• For local plugins it's the config user, because they have to put all the plugins in the correct order into plugins config option

Scripts are easy

Currently tablegen doesn't even change between global and local plguins.

If expandConfig is moved out of mud.config.mts then tablegen would need to wrap loadConfig with expandConfig, but that's it

Hooks are easy

Similar to https://github.com/latticexyz/mud/pull/1007/files so I don't focus on them here much.

If we want local types, this PR might be best done without hooks first, and then we add them separately

[changeset-bot]

⚠️ No Changeset found

Latest commit: e0ef378

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[alvrs]

thanks a lot for this exploration and detailed thoughts!

config definition is harder than globals

const _typedExpandConfig = expandConfig as ExpandConfig<typeof config>;
type ExpandedConfig = MergeReturnType<typeof _typedExpandConfig<typeof config>>;
export default expandConfig(config) as ExpandedConfig;

• I put this scary config expansion in mud.config.mts (which would be bad ux) mostly to show it all in 1 place
• It could be moved to a template so it's right before setupMUDV2Network (it still remains in userland, but more hidden >and unintrusive)
• It can't be moved into setupMUDV2Network because typescript doesn't support higher-kinded types >Allow classes to be parametric in other parametric classes microsoft/TypeScript#1213
• something like https://github.com/pelotom/hkts and forcing plugin authors to use placeholder types seems like the >worst of all options

What if we create a .mud folder in template projects where we can put a extendedConfig.ts with that content? That way it lives in userland but at the same time the complexity is hidden, it's made clear that this should not be edited manually, and we could even have a mud up cli command that both updates the external mud versions and also updates the contents of .mud. (.mud could basically be like another package with its version aligned with the other mud packages, but not installed via npm but rather via mud up). In that .mud directory we could also potentially put other setup files that have to live in userland (thinking of stuff like setup())

Plugin dependencies are harder than globals
It comes down to who has the responsibility for the correct order of plugin dependencies:

For global plugins it's the plugin author, because importing plugin deps needs to happen only once and further imports are ignored
For local plugins it's the config user, because they have to put all the plugins in the correct order into plugins config option

After our recent discussion about hooks I actually think most dependencies between plugins should be based on hooks. If plugin A expects to run after plugin B, it should hook into plugin A's onAfter hook instead of implicit dependencies based on execution order. The only thing where order would matter then would be if a plugin changes the config by deleting a config type, but I don't think that should be endorsed anyway (but rather only adding stuff to the config)

[dk1a]

What if we create a .mud folder in template projects where we can put a extendedConfig.ts with that content? That way it lives in userland but at the same time the complexity is hidden, it's made clear that this should not be edited manually, and we could even have a mud up cli command that both updates the external mud versions and also updates the contents of .mud. (.mud could basically be like another package with its version aligned with the other mud packages, but not installed via npm but rather via mud up). In that .mud directory we could also potentially put other setup files that have to live in userland (thinking of stuff like setup())

This makes config imports roundabout/obfuscated, but most people wouldn't need to import the config and it should be fine. It's certainly better than doing it in mud.config.ts, or setup.ts (which we want to mostly remove I assume)

After our recent discussion about hooks I actually think most dependencies between plugins should be based on hooks. If plugin A expects to run after plugin B, it should hook into plugin A's onAfter hook instead of implicit dependencies based on execution order. The only thing where order would matter then would be if a plugin changes the config by deleting a config type, but I don't think that should be endorsed anyway (but rather only adding stuff to the config)

Hooks seem like a good solution. Resolving multiple parallel dependencies with hooks would be a pain, but I also can't think of an example here

Before we commit to this, have you considered global hooks again, and do you still believe that locals are better?

[alvrs]

Before we commit to this, have you considered global hooks again, and do you still believe that locals are better?

I still think local types are easier to understand for third party developers working on plugins, which I think is the most important factor. Building the foundation for local types on our end might be slightly more complex (lots of typescript black magic) but based on this exploration it seems feasible!

[dk1a]

replaced by #1077
(this PR is a messy prototype, easier to start from scratch and copy some things over)