-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Adds support for PnP #2942
Adds support for PnP #2942
Conversation
Is there a way you could add a test for this? Seems rather complex to test but would be nice if we have a test for it Sent with GitHawk |
Just pushed a commit with a test. I cheat a bit by modifying (then restoring) the environment but it should be fine as long as the tests don't run in parallel 🤞 I also had to commit the result of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Super excited about this.
@@ -60,7 +60,17 @@ class Resolver { | |||
let module = await this.resolveModule(filename, parent); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to adjust this slightly so resolveModule
is not called when using pnp, since that will still look for a node_modules directory (it calls findNodeModulePath
). We'll need to split out the rest of that method so that things like aliases and builtins are still applied, but it doesn't search the filesystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, resolveModule
could also check for pnp and skip looking for node_modules if it is available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, done 👍
Does this also support pnp in yarn v1? Should it? |
@devongovett I haven't tested but it should, yes. The Of course the v2 is so much better anyway 🤡 |
Any blocker? |
Ping ? 😊 |
@arcanis There is a lint error:
|
Ping @devongovett ? 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, although I don't think Parcel 1 should change this significantly and this should probably target Parcel 2
I'm actively waiting on this to support some courses on egghead.io. Is there are part of the change that's too drastic? |
This would be nice to have now. Are you all holding off on this for v2? |
Yes, this PR should be implemented for v2. Alpha's gonna come out soon and Parcel 1 should only receive bugfixes at this point. It could be a seperate resolver plugin in Parcel 2 |
closing in favor of #3582 |
↪️ Pull Request
This PR adds support for PnP to the Parcel resolver.
Related: #2635
💻 Examples
Parcel running under Berry now works 💃
🚨 Test instructions
Unit tests usually are a bit impractical since it requires to run under a different environment (since it relies on
process.versions.pnp
). Any idea? I tested it locally by following the steps in the getting started (absolutely great experience btw!) and adding arequire('lodash')
inindex.js
.To reproduce:
yarn policies set-version berry
yarn --version
to confirm you're running with the v2yarn add lodash
and add therequire('lodash')
toindex.js
yarn parcel index.html
✔️ PR Todo