[ ] Ensure tsx is used throughout development and Vitest adds the vite-tsconfig-paths plugin so that imports also resolve to .ts during dev.
[ ] Implement a build script that creates a temporary tsconfig with compilerOptions.paths set to {} for building so that the build will fail if the tsconfig paths defined for a given package aren't also resolvable in build output. This could then replace tsup and all the corresponding configs could be removed, which would be great for deduplication and simplicity.
[ ] Take an additional pass at the project-specific tsconfig settings, removing as many overrides as possible to standardize behavior across the repo. In some cases these may be needed, but largely the overrides may just be an artifact of the way the tsconfigs were initially defined.
[ ] Migrate to module NodeNext, i.e. .js suffixes on all local imports. Kind of an eye sore, but the settings has lots of other advantages. I think you mentioned wanting to get rid of barrel files- this would be a good change accompanying that. That is unless you want to use Bundler with .ts imports or similar and then have some tool handle converting the build output for you, but if you want to use tsc which I think is ideal for a repo like this, .js endings are probably your best bet.
[ ] In packages/cli/src/commands/set-version.ts on line 85, there was an npmResult that was being implicitly resolved as any due to a resolution issue. That should have an explicit type, but in absence of one existing, I've explicitly typed it as any for now and added a TODO referencing this PR.
[ ] A few packages like CLI which probably shouldn't rely on DOM types do indirectly through utils, e.g.:
packages/cli test:ci: ../common/src/utils/waitForIdle.ts(3,16): error TS2304: Cannot find name 'requestIdleCallback'.
I've added DOM to tsconfig.base.json for now to unblock the build, but eventually utils should probably either be split into a separate package for DOM APIs or have a separate entry point.
[ ] I had to make a few suboptimal changes to get the .abi.json files to resolve to their corresponding .d.ts with a default moduleResolution setting of "bundler" (by default with this setting and resolveJsonModule, the imports seem to resolve to the non-narrowed .json files rather than the .d.ts with narrowed types:
continued from https://github.com/latticexyz/mud/pull/2828
[ ] Ensure
tsxis used throughout development and Vitest adds thevite-tsconfig-pathsplugin so that imports also resolve to.tsduring dev.[ ] Implement a build script that creates a temporary tsconfig with
compilerOptions.pathsset to{}for building so that the build will fail if the tsconfig paths defined for a given package aren't also resolvable in build output. This could then replacetsupand all the corresponding configs could be removed, which would be great for deduplication and simplicity.[ ] Take an additional pass at the project-specific tsconfig settings, removing as many overrides as possible to standardize behavior across the repo. In some cases these may be needed, but largely the overrides may just be an artifact of the way the tsconfigs were initially defined.
[ ] Migrate to module NodeNext, i.e. .js suffixes on all local imports. Kind of an eye sore, but the settings has lots of other advantages. I think you mentioned wanting to get rid of barrel files- this would be a good change accompanying that. That is unless you want to use Bundler with .ts imports or similar and then have some tool handle converting the build output for you, but if you want to use tsc which I think is ideal for a repo like this, .js endings are probably your best bet.
[ ] In
packages/cli/src/commands/set-version.tson line 85, there was annpmResultthat was being implicitly resolved as any due to a resolution issue. That should have an explicit type, but in absence of one existing, I've explicitly typed it asanyfor now and added a TODO referencing this PR.[ ] A few packages like
CLIwhich probably shouldn't rely on DOM types do indirectly through utils, e.g.:I've added
DOMtotsconfig.base.jsonfor now to unblock the build, but eventually utils should probably either be split into a separate package for DOM APIs or have a separate entry point.[ ] I had to make a few suboptimal changes to get the
.abi.jsonfiles to resolve to their corresponding .d.ts with a defaultmoduleResolutionsetting of"bundler"(by default with this setting andresolveJsonModule, the imports seem to resolve to the non-narrowed.jsonfiles rather than the.d.tswith narrowed types:packages/world/tsconfig.json: "resolveJsonModule": false,packages/cli/tsconfig.json: "moduleResolution": "Node",