feat: add TsconfigPathsPlugin #463
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #463 +/- ##
==========================================
+ Coverage 93.13% 93.49% +0.36%
==========================================
Files 45 48 +3
Lines 2155 2305 +150
Branches 654 691 +37
==========================================
+ Hits 2007 2155 +148
- Misses 119 122 +3
+ Partials 29 28 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
xiaoxiaojx
changed the title
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
from
3a9a876 to
9243884
Compare
lib/TsconfigPathsPlugin.js
Outdated
| ? this.configFile | ||
| : resolver.join(process.cwd(), this.configFile); | ||
|
|
||
| const mainOptions = await this.readTsconfigCompilerOptions( |
There was a problem hiding this comment.
I think we can cache readTsconfigCompilerOptions using (and the same for readTsconfigCompilerOptions below)
this.tsconfigProcessorCache = new WeakMap<TS_CONFIG_JSON_VALUE, { aliases: Aliases, references: References }>;So we will read everything only on the first run, and will keep results until GC allow it
Feel free to think how we can avoid more tasks on the second and third calls
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
What if we just store the data on this.tsconfigPathsData?
It doesn’t need to be garbage-collected anyway, so the cache implementation doesn’t have to be too complex.
This comment was marked as outdated.
This comment was marked as outdated.
xiaoxiaojx
changed the title
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
2 times, most recently
from
b1a6c4e to
f45b2f3
Compare
xiaoxiaojx
changed the title
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
from
6af0057 to
49820ff
Compare
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
from
4362983 to
50aa0ca
Compare
lib/TsconfigPathsUtils.js
Outdated
| if ( | ||
| !exists && | ||
| extendedConfigValue.includes("/") && | ||
| extendedConfigValue.includes(".") |
There was a problem hiding this comment.
Can you describe these checks? Maybe we can just check if exist?
There was a problem hiding this comment.
The goal here is to resolve the extendedConfigValue path from node_modules, e.g. extends: "react/tsconfig". Reference: https://github.com/jonaskello/tsconfig-paths/blob/master/src/tsconfig-loader.ts#L187
There was a problem hiding this comment.
lib/TsconfigPathsUtils.js
Outdated
| if (!compilerOptions) return null; | ||
|
|
||
| return { | ||
| ...tsconfigPathsToResolveOptions( |
There was a problem hiding this comment.
We can cache this, look at ExportsFieldPlugin.js plugin, we have this.fieldProcessorCache to cache processed export fields, so let's use the same logic, just using this.tsconfigProcessorCache name and cache result of this function
There was a problem hiding this comment.
The tsconfigPathsToResolveOptions function only runs once per resolve. However, the key of this.fieldProcessorCache is JsonObject(ExportsFieldPlugin.fieldProcessorCache: WeakMap<JsonObject, FieldProcessor>), and since each resolve produces a different JsonObject reference, this cache becomes ineffective in scenarios where it should run only once per resolve. This makes me wonder whether the cache in ExportsFieldPlugin(this.fieldProcessorCache) aligns with the original intent—perhaps the key should be a string rather than an object reference.
|
Add let's add more test cases to improve coverage |
No description provided.