Use declaration maps for improved local development #2361
Conversation
The correct one is /.vscode/settings.json
| @@ -89,7 +89,7 @@ jobs: | |||
|
|
|||
| - name: Build all packages | |||
| run: | | |||
| npm run build -- --filter='./packages/*' | |||
| NODE_ENV="production" npm run build -- --filter='./packages/*' | |||
There was a problem hiding this comment.
Not really sure how I feel about relying on NODE_ENV for this.
Would it be an option to simply always let the declaration maps be generated (also in production), but simply not include them in the NPM bundle by excluding their file extension?
"files": [
"dist/**",
"!**.d.ts.map", 👈
"README.md"
],
There was a problem hiding this comment.
This exclude pattern works, I just tested it locally 👍
There was a problem hiding this comment.
The biggest reason is that I'm not 100% confident that the different .d.ts outputs don't lead to differences, but if they don't, I'll find a way to duplicate them as .d.cts and I agree having a single path would be easier and more predictable
There was a problem hiding this comment.
I tried to simplify things with the "single output" option but I think I've reached a dead-end: generating the .d.ts files with tsc separately from the code leads to different file structures and publint links that to an "Internal resolution error" with node16 resolution (see image in PR description) 😢 Fixing this seems like a rabbit hole I don't want to go into atm but there's still the option of two outputs:
- local: break
node16resolution but gain declaration maps - production: same output as before this PR
And we could use something else thanprocess.env.NODE_ENVto switch between local and production
This PR aims to allow navigating between the various
packagesmonorepo projects by using TS' declaration maps, currently⌘ + clicknavigates todistoutputs.Note: tsup doesn't support them 😢
Experiments/learnings
When we generate
.d.tsfiles ourselves separately from.jsfiles, their bundling differs (in both tsup and Rollup projects) and breaksnode16TS resolution according to arethetypeswrong, so we can't do that for the builds that get published on npm.I also experimented with the new tsdown (which unlike tsup supports declaration maps), but on top of unrelated problems because it's so new, I couldn't get the seemingly-correct maps to be picked up by TS in my editor.
Solution
After trying a bunch of possible setups, the one I landed on is:
.envrcfiles are responsible for automatically opting-in to declaration maps (by setting theDECLARATION_MAPSenv variable) locally. When enabled,.d.tsare manually created with their declaration maps, breakingnode16TS resolution. Our examples and projects don't usenode16resolution so there's no downside for us locally, but we gain declaration maps..envrcfiles will act like before, so our npm builds will supportnode16resolution as before.