Repository navigation
perf(deps): read each package.json once when resolving dep subpaths - #1093
Conversation
✅ Deploy Preview for tsdown-main ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
tsdown
create-tsdown
@tsdown/css
@tsdown/exe
tsdown-migrate
commit: |
d9932ed to
8248a43
Compare
Andrew-Smith-93
left a comment
Andrew-Smith-93
left a comment
There was a problem hiding this comment.
tests/e2e.test.ts:1490
Could we add a focused DepsPlugin cache test? Concurrent subpath resolutions sharing one packageJsonPath should cause one read for the exports check. After buildStart, the same plugin should reread it and observe a changed exports field. The current output test would pass without caching, so it doesn’t protect read deduplication or rebuild invalidation.
|
yeah that makes sense. Added a unit test in |
Replace the exports-only cache with a package.json cache that readBundledDepInfo also uses, so bundled modules of a package no longer re-read its package.json either.
|
Thanks for adding the tests, @Cherry. The final version covers concurrent lookups sharing one read and rereading after buildStart, which addresses my suggestion. Glad to see it merged! |
AI usage
Description
With
deps.resolveDepSubpathturned on, every subpath import reads and parses the dependency'spackage.jsonagain just to check forexports. We noticed it in one of our builds, which parseddrizzle-orm's 177 KBpackage.jsonover 5,000 times.This caches that check per
package.jsonfor the build, and clears it onbuildStartso watch rebuilds still pick up changes. On a fixture with 600 files importing subpaths of one big package, our builds went from ~1.75s to ~0.5s, about the same as with the option off.Added a test that imports subpaths of a package with
exportsand one without, from a couple of files, to make sure each package still gets its own answer.