Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #463 +/- ##
==========================================
+ Coverage 93.14% 93.40% +0.26%
==========================================
Files 45 49 +4
Lines 2158 2381 +223
Branches 654 716 +62
==========================================
+ Hits 2010 2224 +214
- Misses 119 128 +9
Partials 29 29
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.
alexander-akait
left a comment
alexander-akait
left a comment
There was a problem hiding this comment.
Added comments, also let's add test cases, good start for this plugin, thank you
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
2 times, most recently
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.
There was a problem hiding this comment.
The previous conclusion was incorrect — if we use fileSystem.readJson, it returns the same JsonObject reference.
https://github.com/webpack/enhanced-resolve/blob/main/lib/DescriptionFileUtils.js#L104
The same caching logic can't be applied to tsconfigPaths because tsconfigPaths might be a JSON that combines multiple "extends", and the references will always be new. The cost of caching won't be less than that of running the original function.
|
Add let's add more test cases to improve coverage |
lib/TsconfigPathsPlugin.js
Outdated
| module.exports._getPrefixLength = getPrefixLength; | ||
| module.exports._mergeTsconfigs = mergeTsconfigs; | ||
| module.exports._sortByLongestPrefix = sortByLongestPrefix; | ||
| module.exports._tsconfigPathsToResolveOptions = tsconfigPathsToResolveOptions; |
There was a problem hiding this comment.
Do we need to expose it? For testing purposes?
lib/index.js
Outdated
| extensions: [".js", ".json", ".node"], | ||
| useSyncFileSystemCalls: true, | ||
| fileSystem: getNodeFileSystem(), | ||
| tsconfig: false, |
There was a problem hiding this comment.
Do we need to pass false here?
README.md
Outdated
| | restrictions | [] | A list of resolve restrictions | | ||
| | roots | [] | A list of root paths | | ||
| | symlinks | true | Whether to resolve symlinks to their symlinked location | | ||
| | tsconfig | true | Path to tsconfig.json for paths mapping. Default true loads tsconfig.json, or pass a string path. | |
There was a problem hiding this comment.
It should be false by default
lib/TsconfigPathsPlugin.js
Outdated
| } | ||
|
|
||
| const content = await new Promise((resolve, reject) => { | ||
| fileSystem.readFile(jsonFilePath, "utf8", (err, data) => { |
There was a problem hiding this comment.
Let's avoid using utf8 for any reads for caching purposes
|
@xiaoxiaojx Looked at code, and it looks good, let's do some options refactor like oxc have for typescript - https://github.com/oxc-project/oxc-resolver?tab=readme-ov-file#typescript-configuration, i.e. |
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
8 times, most recently
from
f07913d to
b2f5489
Compare
xiaoxiaojx
force-pushed
the
feat/tsconfigPaths
branch
from
006f4b1 to
1f2d6a7
Compare
2 participants
No description provided.