-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(store,world): enable namespaces input #2968
Conversation
holic
commented
Jul 23, 2024
•
edited
Loading
edited
- multiple namespace tests
- validate that each namespace is only specified once (since the same namespace can be used with diff labels)
- output table libs to namespaced dirs
- support deploying systems from namespace dirs
- enable systems input in namespaces
🦋 Changeset detectedLatest commit: 78ff2fa The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 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 |
cad0ffb
to
ec80234
Compare
} | ||
} | ||
// Copied from store/ts/config/v2/namespaces.ts but using world namespace validate/resolve methods | ||
// TODO: figure out how to dedupe these? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alvrs Curious if you have any ideas/strategies for this kind of thing. It's similar to table shorthands where we need to deeply extend particular things (in this case extending store namespaces with systems).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't really have a good strategy for this either :/
* | ||
* Defaults to `true` when using top-level `namespaces` key, `false` otherwise. | ||
* @deprecated We recommend importing directly from table libraries rather than from the index for better compile times and deterministic deploys. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooc do we know that it impacts compile times?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't measured it but it's very likely given 1) more files need to be compiled, even if not used and 2) reports from @0xhank and others on more files = worse compile times (which may be fixable upstream in forge/foundry/solc)
The main motivation to deprecate this here is that any change to tables impacts bytecode of all things import index.sol
, even if they aren't importing the table that changed. Which means systems become less consistent in terms of bytecode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥🔥🔥