-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add isEntry flag to resolveId and this.resolve #4230
Conversation
Thank you for your contribution! ❤️You can try out this pull request locally by installing Rollup via npm install rollup/rollup#resolve-id-is-entry or load it into the REPL: |
Codecov Report
@@ Coverage Diff @@
## master #4230 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 203 203
Lines 7341 7342 +1
Branches 2087 2088 +1
=======================================
+ Hits 7223 7224 +1
Misses 58 58
Partials 60 60
Continue to review full report at Codecov.
|
@yyx990803 @patak-js tagging you as this is a (minor) extension to the plugin API that may or may not be relevant for you to implement. Please tell me if I should tag other people for such things in the future. This flag will become relevant for the CommonJS plugin at some point (but there is a bigger one I am working on that will likely have more impact for you). |
8530bad
to
ed35228
Compare
ed35228
to
a3f4bc0
Compare
LGTM. Just to clarify here, a dynamic import that becomes an emitted chunk would have |
Thanks for the heads up @lukastaegert. It is relevant, as we need to implement it in the plugin pipeline of Vite dev server. LGTM. I started a branch in Vite to see what changes are needed on Vite side (see commit). We would need to review later with proper test cases but this looks straightforward. About other people that may be interested in these changes, @antfu from Vite's side and @marvinhagemeister, as they would need to do the same for WMR A note about extending the plugin API, Vite added an export function mySSRPlugin() {
return {
name: 'my-ssr',
transform(code, id, ssr) {
if (ssr) {
// perform ssr-specific transform...
}
}
}
} |
@guybedford the dynamic import would be resolved twice: Once for the import itself where @patak-js I will need to think about this more, but one first thought is that a plain boolean parameter may not be forward looking. If you want to add more parameters in the future, you will be happy if you make it an object now. At this point, one could consider merging with Rollup‘a object if you do not add too much stuff that Rollup cannot use in the future :) |
@patak-js Expanding more on the idea of how to add a flag to Rollup's hooks that will not interfere with future extensions:
|
Thanks for taking the time to share your experience here @lukastaegert, moving this discussion to vitejs/vite#5109 to avoid derailing this PR. |
@patak-js Thanks for tagging me! Nothing more to add other than that this feature really helps us both vite and other bundlers 👍 So thanks @lukastaegert for adding it 🙌 |
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description
In the past, the way to detect if we are resolving an entry point in the
resolveId
hook was to check if theimporter
wasundefined
. However since we allowed to specify animporter
in thethis.emitFile
hook, this check does not work in all cases any more.This is problematic if you want to resolve entry points (and only those!) to proxies in a reliable manner.
This PR adds a new flag
isEntry
to theresolveId
plugin hook to make this explicit. The same flag is also added to thethis.resolve
plugin context function. So resolving entries to plugins would now work like this:In the
resolveId
hook, the value ofoptions.isEntry
is determined like this:true
false
this.resolve
andisEntry
is a boolean, this value is used, e.g.this.resolve('foo', 'bar', {isEntry: true})
this.resolve
andisEntry
isundefined
(or we did not specify options at all), it istrue
ifimporter
isundefined
, otherwise it isfalse
The reason I need this is that I want to do exactly that in a forthcoming PR for the commonjs plugin (with the goal of handling circular dependencies correctly).
Once this is release, plugins should check if they need to forward this flag when they use
this.resolve
. It should be possible to implement support for this flag in a manner that is compatible with older Rollup versions (here you would just forwardundefined
which would trigger the fallback logic).