feat: support systems without System suffix #3649
Conversation
🦋 Changeset detectedLatest commit: ab0ad91 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| @@ -22,10 +22,22 @@ export async function getSystemContracts({ | |||
| pattern: path.join(config.sourceDirectory, "**"), | |||
| }); | |||
|
|
|||
| // Get systems from the top-level systems object | |||
| const topLevelSystems = Object.keys(config.systems); | |||
There was a problem hiding this comment.
no need for this! the top level config is also mirrored to the namespaces config (the default entry point for tooling)
|
|
||
| // Get systems from namespaces | ||
| const namespaceSystems = Object.values(config.namespaces || {}).flatMap((namespace) => | ||
| Object.keys(namespace.systems || {}), |
There was a problem hiding this comment.
ideally we map these to namespace.label rather than key to keep tooling consistent
There was a problem hiding this comment.
now I'm doing: Object.values(namespace.systems).map((system) => system.label),, let me know if that is what you meant
There was a problem hiding this comment.
sorry, the namespaces flatMap is the "standard" path for this kinda thing
| return solidityFiles | ||
| .filter( | ||
| (file) => | ||
| file.basename.endsWith("System") && | ||
| // Include files with the System suffix and files defined in config | ||
| (file.basename.endsWith("System") || configSystemLabels.includes(file.basename)) && |
There was a problem hiding this comment.
My only concern with this approach is if a system name provided by the MUD config conflicts with any other contract name (including codegen). I think I avoided filtering out codegen dirs here because how those dirs are determined is a bit complex (and somewhat dependent on the source dir structure).
Some other ideas on my mind:
- config option for
isSystemSource: () => boolwhere we'd provide this behavior by default but it could be added to or overridden - config option for
systemSuffix: RegExpwhere the default is something like/System$/but could be overridden to something like/(System|Program)$/
In an ideal world, we'd be able to parse the Solidity source and check if anything inherits from the base System contract and use that as an indicator, but I recall running into chicken-and-egg problems when I moved source parsing earlier in the stack, where a system may depend on table libs or world/system interfaces that don't exist yet.
There was a problem hiding this comment.
Curious to hear @alvrs's thoughts
TODO: add tests