Feature/composite monorepo #8560
Conversation
so that tests can pick up the path aliases
github-actions
bot
added
package: react-query-devtools
package: react-query
package: react-query-persist-client
package: vue-query
package: query-core
package: solid-query
package: query-persist-client-core
package: eslint-plugin-query
package: svelte-query
package: svelte-query-devtools
package: query-devtools
package: angular-query-experimental
package: angular-query-devtools-experimental
package: query-async-storage-persister
package: query-codemods
package: query-sync-storage-persister
package: solid-query-persist-client
package: svelte-query-persist-client
package: vue-query-devtools
package: solid-query-devtools
package: query-broadcast-client-experimental
package: react-query-next-experimental
labels
|
Sizes for commit 14f24df:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8560 +/- ##
=======================================
Coverage 46.28% 46.28%
=======================================
Files 199 199
Lines 7538 7538
Branches 1721 1724 +3
=======================================
Hits 3489 3489
Misses 3670 3670
Partials 379 379 |
…TS versions""" This reverts commit 79b4844.
|
Drive by review (I saw this on bluesky):
In a composite build Speaking of referencing from the root, I would suggest not putting anything in the config at the very root of the repo, instead making that a "solution" tsconfig whose only role it is to help tsserver find other configs (or to do a big typescript-eslint/typescript-eslint#10361 is also something you might want to look at, since it's also a project moving to this layout and also using nx (which I believe is currently undergoing a refactor to be able to generate the exact thing you want).
I'm surprised you need path aliases at all; in a monorepo those are usually very well covered by the package manager doing symlinking and then imports "just work". Path aliases are (IMO) best avoided beacuse they entirely bypass any and all module resolution logic (which may hide issues). |
good to know 👍 , I don’t mind the explicitness though.
I tried to remove the path aliases, and tests then only work after I’ve made a build. It also doesn’t immediately respect changes in a dependent config, and code navigation in the IDE will take me to the
Yeah I’ll rethink this as a follow-up. The eslint config for example shouldn’t be needed at all because we have the flat config. |
This reverts commit 97f5544.
How are you testing without building? I would have expected whatever's enabling that no-build setup (vitest? Some other thing) to be able to find the source instead, but maybe that requires doing something like https://colinhacks.com/essays/live-types-typescript-monorepo |
|
yeah, like the article says:
I just let it point to |
|
Right, I was just trying to understand who's in charge of running TS source directly. |
This PR changes the structure of our monorepo towards a
compositetypescript setup.In a composite monorepo, each package can be built in isolation with TSC to provide types other packages can consume. This has the following advantages and fixes the following issues:
Code Navigation
Clicking on an import in your IDE that imports something from a dependent package, like:
in a framework adapter used to take you to the
.d.tsfile in thebuilddirectory. Now, it takes you directly to the source.Changes are picked up immediately
Because packages are linked together by sources via typescript path aliases, a change in
query-corewill automatically highlight all errors in your editor in adapter files. Previously, a build was needed, and oftentimes also a restart of the ts language server in your editor.Tests
Tests also know about typescript path aliases thanks to the
vite-tsconfig-pathspackage (and dynamic path aliases, which are necessary to override what we have inpackage.jsonas main/exports entries). That means we can add a log statement to aquery-corefile and execute a test in a framework adapter without an in-between build step.No build dependency
All tasks like linting and type checking no longer need a
buildof dependent packages - they do need acompiletask though that instructs typescript to build the output.Things changed
New
compiletask(Mainly) to make CI work, we have a new
compiletask that will instruct tsc to build all packages. For this, I had to switch svelte packages towards"moduleResolution": "Bundler". I hope this doesn’t break anything @lachlancollinsIsolated packages
Packages need to be isolated, so the
rootDirwas always set to”.”. However, we have imported things from../../, like the global eslint config. To work around this, I’ve created symlinks within therootDirof all packages, because those imports were no longer allowed.References
Each package must define its own dependencies as
referencesintsconfig.json. Those reference point towards other packages, so that typescript can know about the build graph. This has to be kept in-sync withworkspacedependencies inpackage.jsonPath mappings
TypeScript path mappings are defined in the root
tsconfigjson. All packages must be listed there - this is also what we use to buildaliasesfor theviteconfigs.