-
Notifications
You must be signed in to change notification settings - Fork 36
Fix plugins not being found when no node_modules exists #171
Conversation
This test should pass when it has been updated to use resolve
Assume resolve returns an entry file not a directory
Thanks for the contribution! Before we can merge this, we need @TPHRyan to sign the Salesforce.com Contributor License Agreement. |
Codecov Report
@@ Coverage Diff @@
## master #171 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 2 2
Lines 12 12
Branches 3 3
======================================
Misses 12 12 Continue to review full report at Codecov.
|
@jdxcode anything missing here? this issue is preventing apollo tooling from running under yarn 2 |
Any movement on this PR? It's been a long while, and this would help quite a few packages that depend on it to move to Yarn 2. |
I don't see any problem with this, but I want to try it out. @AaronBuxbaum have you also been able to try this PR to confirm that it works and doesn't break any existing functionality? I hope you have also seen the announcement about oclif/core. I'm assuming that library will also have that problem? @TPHRyan could we also do a PR there as well? |
Yes, I'm using it now and as far as I'm concerned there are no issues at all with this. It's a dependency of a different library, so it's a limited test case, but it looks solid to me. |
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.
When I link this with https://github.com/salesforcecli/sfdx-cli/ it blows up. Passing in basedir as mentioned in the comments fixes some errors, but it still doesn't resolve everything. I don't have the time right now to try to see why it is still failing. Unless we can see why resolve
isn't finding the packages, we may have to add in the old code as a backup if resolve can't find it.
if (name) { | ||
let pkgPath | ||
try { | ||
pkgPath = await resolvePackage(name) |
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.
I think you need to pass in { basedir: root }
because it may need to look outside of the current path. i.e. where user plugins are stored.
With that said, the resolve
library isn't working how I thought it would. If I add the basedir above, it will still sometimes throw MODULE_NOT_FOUND
even though it seems to be in the resolution path.
For example, I modified resolvePackage to take in the same options object that resolve takes and pass that to resolve.
// name = '@salesforce/plugin-evergreen-build'
// root = '/Users/t.dvornik/.local/share/sfdx/node_modules/@salesforce/plugin-evergreen'
...
// The root may not always be a dir, so ensure it is before passing it into resolve
if (path.extname(root)) {
root = path.dirname(root)
}
try {
pkgPath = await util_2.resolvePackage(name, { basedir: root });
}
...
That package is in /Users/t.dvornik/.local/share/sfdx/node_modules/@salesforce/plugin-evergreen-build
which should be in node module resolution but resolve isn't resolving it.
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.
Thanks for looking at this - this issue flew under the radar for me for a minute, but I'll have a look to see if I can fix it sometime soon. It's not high priority for me but evidently there's a few others others also waiting on a fix.
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.
Any reason we don't just use the native require.resolve
over the resolve
package? it doesn't appear that we really need it to resolve asynchronously for our use case.
Any progress on this? @TPHRyan I'm hoping to use workspaces in my Yarn 2 repo, but that throws errors from @oclif/config even with the existing patch that previously worked:
this is effectively the same setup as previously worked, except with a workspace that now owns the percy and oclif packages, instead of directly on root |
As a workaround, you can tell Yarn 2 to use node-modules instead of pnp. .yarnrc.yml nodeLinker: node-modules Reference: https://yarnpkg.com/configuration/yarnrc/#nodeLinker |
For me at least, that doesn't do it, though it could be that it's not actually oclif here, I haven't dug into it
It's also not a greaaat solution even if it did work because the node_modules linker defeats a lot of the purpose of Yarn 2 |
can we get this merged already?? |
@peternhale. Would you mind taking a look at this? It seems to be blocking a lot of people. 🙏 |
@TPHRyan Sorry for the delays on this PR! I'll merge this PR once we're done testing on our end. I'd strongly suggest that you open a PR with the same changes against oclif/core since this project will be going into maintenance mode in the next 1-2 weeks once core is officially released |
This reverts commit e5739c4.
@TPHRyan Despite our internal testing, we encountered a bug with this change in the sfdx cli after it was published: forcedotcom/cli#1300 I decided to revert the commit for now. I'm happy to merge your changes again once you come up with a fix |
@mdonnalley I have forked and updated this pr in #289 let me know if that fixes the issues |
Fixes #170.
As I mentioned in the issue, Yarn 2 uses a different package system that does not have node_modules. As such, relying on node_modules should be discouraged.
Yarn suggests using the
resolve
package, and this is the approach I have taken.Please let me know if any further changes are required. I tried to conform to idioms of the code, but for testing in particular I wasn't sure what the guidelines were.