refactor: inline loader-runner package into core#21249
Conversation
🦋 Changeset detectedLatest commit: 262242f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #21249 +/- ##
==========================================
+ Coverage 92.77% 92.89% +0.11%
==========================================
Files 591 597 +6
Lines 64467 65307 +840
Branches 17911 18243 +332
==========================================
+ Hits 59808 60665 +857
+ Misses 4659 4642 -17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
- Introduced multiple loader implementations including identity, async, promise, and pitch loaders. - Added binary files for testing purposes, including 'bom.bin' and 'resource.bin'. - Implemented loaders that handle dependencies, context dependencies, and missing dependencies. - Created loaders that return modified source strings and handle raw data. - Added tests for loaders that throw errors and return promises. - Included examples of setting resource paths and handling async operations in loaders.
Merging this PR will not alter performance
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Memory | benchmark "asset-modules-inline", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
381.2 KB | 1,195.3 KB | -68.11% |
| ❌ | Memory | benchmark "wasm-modules-sync", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
131.8 KB | 364.7 KB | -63.86% |
| ❌ | Memory | benchmark "asset-modules-bytes", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
247 KB | 322.6 KB | -23.43% |
| ⚡ | Memory | benchmark "many-modules-esm", scenario '{"name":"mode-development","mode":"development"}' |
1.9 MB | 1.2 MB | +66.39% |
| ⚡ | Memory | benchmark "many-chunks-esm", scenario '{"name":"mode-production","mode":"production"}' |
11.4 MB | 8.7 MB | +31.34% |
| ⚡ | Memory | benchmark "wasm-modules-async", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
250.2 KB | 195.3 KB | +28.13% |
| ⚡ | Memory | benchmark "future-defaults", scenario '{"name":"mode-production","mode":"production"}' |
8.7 MB | 7.1 MB | +23.58% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing bjohansebas:refactor/inline-loader-runner (262242f) with main (54fa902)
…n LoaderRunner tests
|
@alexander-akait after this, I'm going to look into the improvements Rspack has regarding loader caching. |
| missingDependencies.length = 0; | ||
| requestCacheable = true; | ||
| }; | ||
| Object.defineProperty(loaderContext, "resource", { |
There was a problem hiding this comment.
Let's use modern ES syntax here, also I am thinking about implement a function createLoaderContext and move from normal module all logic related to loader context in this function, so it will be more readable, now we have multiple places to create a loader context, it is not good
… for improved structure
…context management
|
|
||
| // add accessors last (keeps fast properties) and freeze, now that callers | ||
| // (e.g. NormalModule's beforeLoaders) have populated the context | ||
| Object.defineProperties(loaderContext, ACCESSORS); |
There was a problem hiding this comment.
Using defineProperties is consistently faster than defineProperty or class methods. I saw roughly a 9% performance improvement, especially in cases like Babel and other similar tooling.
Summary
This comes from the roadmap
Same content, just with typos.
What kind of change does this PR introduce?
Did you add tests for your changes?
Does this PR introduce a breaking change?
If relevant, what needs to be documented once your changes are merged or what have you already documented?
Use of AI