Add processor cache in webpack loader #1912
Conversation
Backports: wooorm/xdm@decafe9. Related-to: GH-1468.
wooorm
added
🦋 type/enhancement
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| @@ -21,20 +27,25 @@ export function loader(value, callback) { | |||
| /** @type {Defaults} */ | |||
| const defaults = this.sourceMap ? {SourceMapGenerator} : {} | |||
| const options = /** @type {CompileOptions} */ (this.getOptions()) | |||
| const config = {...defaults, ...options} | |||
There was a problem hiding this comment.
The config object is constructed here. This is always a new object by reference. It’s then used as a key in the weak map cache. Once the loader is done processing a file, the config object is unused and garbage collected, meaning it’s removed from the cache.
This means the cache is never used.
If options is always the same object, that could be used.
There was a problem hiding this comment.
Is options a reference to the same object? Seems to weird that this.getOptions() would do that.
There was a problem hiding this comment.
I don’t know. That’s why I wrote if.
I think it might be the same object if options are passed to the loader as an object, but not when they are passed as a query parameter. I’m really just guessing here though.
There was a problem hiding this comment.
We can still use this.query though?
There was a problem hiding this comment.
…assuming that worked before, you tested it?
There was a problem hiding this comment.
Yes, I tested it back then. If query is the raw object, that’s probably our best option. Just beware it might also be a string, which can’t be used as a key for weak maps.
It was heavily inspired by ts-loader. They use a similar approach here.
Also when I implemented it, this was compatible with Webpack 4. The use of getOptions() indicate this is no longer the case. I don’t know if the use of Webpack 5 opens up better alternatives.
There was a problem hiding this comment.
ts-loader has a similar approach but caches on webpack compilers. Should we use those instead?
There was a problem hiding this comment.
I think it doesn’t affect most users, as most users instantiate a single compiler, but it’s still a good idea.
There was a problem hiding this comment.
TS uses a rather complex hash though: https://github.com/TypeStrong/ts-loader/blob/dcec071c110bff12d9d510a35869395862e4a6eb/src/index.ts#L182.
Which is then passed through here as the name here, which is finally used here
Backports: wooorm/xdm@decafe9.
Related-to: GH-1468.