-
Notifications
You must be signed in to change notification settings - Fork 192
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 #168
Adds support for PnP #168
Conversation
Maël Nison seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
Codecov Report
@@ Coverage Diff @@
## master #168 +/- ##
==========================================
- Coverage 92.98% 92.97% -0.01%
==========================================
Files 32 33 +1
Lines 1140 1167 +27
Branches 262 269 +7
==========================================
+ Hits 1060 1085 +25
- Misses 80 82 +2
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #168 +/- ##
==========================================
+ Coverage 92.98% 93.04% +0.06%
==========================================
Files 32 33 +1
Lines 1140 1165 +25
Branches 262 270 +8
==========================================
+ Hits 1060 1084 +24
- Misses 80 81 +1
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #168 +/- ##
==========================================
- Coverage 92.98% 92.97% -0.01%
==========================================
Files 32 33 +1
Lines 1140 1167 +27
Branches 262 269 +7
==========================================
+ Hits 1060 1085 +25
- Misses 80 82 +2
Continue to review full report at Codecov.
|
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
One potential issue - in the case of the |
|
What's the intended semantic difference between |
Ping? 😃 |
@arcanis Can you accept CLA? |
Done 👍 |
lib/ResolverFactory.js
Outdated
@@ -280,7 +290,8 @@ exports.createResolver = function(options) { | |||
aliasFields.forEach(item => { | |||
plugins.push(new AliasFieldPlugin("file", item, "resolve")); | |||
}); | |||
if (symlinks) plugins.push(new SymlinkPlugin("file", "relative")); | |||
if (symlinks && !pnpApi) |
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.
Why is this necessary?
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.
Because ambiguities with require.resolve
, whose return value is used both as input for readFile
and require
. This property means that the return value of require.resolve
must both be a valid filesystem path, and a unique identifier for require
call.
It doesn't cause issues in general cases, except when using peer dependencies - in this case you cannot uniquely identify a package via its location on the disk, because it might be instantiated multiple times in the dependency tree (each time with a different set of dependencies). In order to solve this, Yarn generates "virtual packages" for all packages that list peer dependencies, which effectively are symlinks to the cache. The symlink doesn't do anything, except that it gives semantic information used in the resolution (for example webpack-cli-abc
would be registered with webpack@1.0.0
in its dependencies, while webpack-cli-123
would be registered with webpack@2.0.0
- even though both would use the same symlink target of /cache/webpack-cli-1.0.0
).
In order to work properly, this behavior requires the symlinks to be preserved, otherwise we lose the information previously stored.
I'll add a comment linking to this comment.
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.
hmm I understand the issue, but this need to be solved in some other way. Currently this change alters symlink behavior for all paths even non-pnp paths (i. e. local paths). It's ok to disable symlinks, but only for pnp-resolved paths.
You can do this i. e. by adding a flag to the request
(i. e. keepSymlinks
) when resolved by the pnp plugin and handle this flag in the SymlinkPlugin.
All clear @sokra 👍 |
Ping? |
lib/ResolverFactory.js
Outdated
@@ -280,7 +290,8 @@ exports.createResolver = function(options) { | |||
aliasFields.forEach(item => { | |||
plugins.push(new AliasFieldPlugin("file", item, "resolve")); | |||
}); | |||
if (symlinks) plugins.push(new SymlinkPlugin("file", "relative")); | |||
if (symlinks && !pnpApi) |
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.
hmm I understand the issue, but this need to be solved in some other way. Currently this change alters symlink behavior for all paths even non-pnp paths (i. e. local paths). It's ok to disable symlinks, but only for pnp-resolved paths.
You can do this i. e. by adding a flag to the request
(i. e. keepSymlinks
) when resolved by the pnp plugin and handle this flag in the SymlinkPlugin.
@sokra I'm not convinced it's either possible or desirable - imagine a file making an import via a relative path, should the symlinks be resolved or not? Now imagine that the issuer is a PnP package, how does that affect your answer? Now imagine that it's not a package but a workspace, how does that change things? And what's the risk that the difference in environment would cause a package to work locally (where it would be "not-pnp") and break elsewhere (where it would be a package and thus "pnp")? Wouldn't it be solved simply by documenting the behavior as expected? This can be revisited if we get bug reports, but I'd argue that it might be worth trying as initial implementation. If still have concerns, what do you think of making the default of // Resolve symlinks to their symlinked location
const symlinks =
typeof options.symlinks !== "undefined" ? options.symlinks : !pnpApi; |
@sokra I went ahead and updated the PR with the solution I mentioned. Is it better? |
Ping? 😊 |
Ping 😔 |
Thanks a lot! 😊 |
I understand that @sokra doesn't have the bandwidth, but is there someone else that could help drive this forward? It pains me to see that this issue has been opened for half a year now. It also makes it way harder for me to plan accordingly for the project I manage, which happens to be a critical Webpack dependency. As I said before I'm more than willing to refactor or to explain the design, but I can't be expected to continue sending pings. Remember I'm also doing this because I think it would provide value to Webpack and Webpack's users too ... |
@arcanis in priority list, answer will be in near future (day - two day) |
fixes #168 Co-authored-by: Maël Nison <nison.mael@gmail.com>
Awesome! What are the implications of this going in @arcanis? Does this mean pnp-webpack-plugin doesn't need to exist anymore? |
@johnnyreilly It will still be needed for people using TypeScript, to provide the hooks it contains - although maybe we could just support it by default if you're ok with it, since it's very little code 😃 |
Make it happen! 😁 |
This PR adds a small PnP plugin, and the associated tests.
Fixes #162