fix(store,world): fix tsc
errors in projects depending on @latticexyz/store-sync
#1974
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Projects created by
create-mud
are currently failing theirpnpm test
scripts due to TypeScript type checking errors. This pull request addresses this issue and also resolves #1958.Steps to Reproduce
Cause
These errors occur because the published
store
andworld
packages don't contain the/mud.config.ts
files. In the MUD repository's/templates/vanilla/
, these errors don't occur, as it uses locally linked dependencies (like"@latticexyz/store-sync": "link:../../../../packages/store-sync"
).In the
package.json
files of bothstore
andworld
, thetypesVersions
fields for TypeScript don't include/mud.config
, so the@latticexyz/<name>/mud.config
imports are resolved by their file paths.Fix
To resolve this, I've added
!mud.config.ts
to the.npmignore
files of bothstore
andworld
to include these files in the published packages.To verify the fix of these errors, you can follow these steps after checking out this branch:
Note
While this fix addresses the immediate issue for projects with
store-sync
dependencies, I'm considering whether the current packaging approach of usingtypesVersions
is optimal. Currently, users are required to havemoduleResolution: node10
in theirtsconfig.json
, but I prefer usingnode16
orbundler
for my project. I believe this topic has already been discussed within the team. If there are any established ideas or directions regarding this issue, I'd be eager to learn and contribute.