-
Notifications
You must be signed in to change notification settings - Fork 213
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
feat: proper yarn workspace support #379
Conversation
I'm also not too excited to simply duplicate npm's internal behavior. Any chance we can simply depend on |
Unfortunately not really, running npm-ls on a yarn workspace installed package just results in a lot of errors because the package are not where they are expected. Furthermore we cannot even rely on the basic node resolution capabilities ( From the issue you linked it seems that even npm ls is problematic anyway... |
@joaomoreno any chance for you to have a deeper review on this ? |
Would love to see this reviewed! The change would unblock adoption of yarn workspaces for our project. |
@nlunets Looking into this. Can you give me a concrete example of an extension which would depend on this? Also, would it be enough to simply detect |
@joaomoreno, here's a example repo you can test against: https://github.com/ullasholla/yarn-workspace-test
|
@joaomoreno, have you had a chance to look at this? Cheers. |
Thanks @nlunets for sending the patch. |
And I take some(ok, all) responsibility that yarn ls command sucks in workspaces mode :( @joaomoreno, any chance this can be accepted? |
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.
And I take some(ok, all) responsibility that yarn ls command sucks in workspaces mode :(
It just slipped through the cracks.
Now it's a bit too late with Yarn V2 being imminent.
What do you mean?
const files = fileNames.map(f => { | ||
// In case of a yarn workspace the filepath can point to node_modules at a higher level, we can just strip that within the extension | ||
let basePathF = f; | ||
while(basePathF.indexOf('../') === 0) { |
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.
Did you test this on Windows? Also, please do not use indexOf
to check for a prefix...
let dependencyPath; | ||
let newPrefix = prefix; | ||
// Follow the same resolve logic that is used within npm / yarn | ||
while(newPrefix !== "/" && !dependencyPath) { |
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.
Works on Windows?
if(!dependencyPath) { | ||
dependencyPath = path.join(prefix, "node_modules", name) | ||
} | ||
const depPackage = require(path.join(dependencyPath, "package.json")); |
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.
Do not use require
to load a JSON file from disk.
const usingPackagedDependencies = Array.isArray(packagedDependencies); | ||
const trees = JSON.parse(match[0]).data.trees as YarnTreeNode[]; | ||
const rootPackage = require(path.join(cwd, 'package.json')); |
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.
Do not use require
to load a JSON file from disk.
const usingPackagedDependencies = Array.isArray(packagedDependencies); | ||
const trees = JSON.parse(match[0]).data.trees as YarnTreeNode[]; | ||
const rootPackage = require(path.join(cwd, 'package.json')); | ||
const trees = Object.keys(rootPackage.dependencies); |
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.
Instead of trees
, shouldn't it be packages
? Or dependencies
?
@@ -837,7 +837,14 @@ export function collect(manifest: Manifest, options: IPackageOptions = {}): Prom | |||
const processors = createDefaultProcessors(manifest, options); | |||
|
|||
return collectFiles(cwd, useYarn, packagedDependencies).then(fileNames => { | |||
const files = fileNames.map(f => ({ path: `extension/${f}`, localPath: path.join(cwd, f) })); | |||
const files = fileNames.map(f => { |
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'd rather we change the return values of collectFiles
to return absolute paths instead of hardcoding yarn workspaces knowledge down here.
Never mind, I implemented the workspaces in yarn and did not realize that list command got broken. |
I was a bit too eager on this PR, turns out it goes into infinite loop in some cases. |
@nlunets, I've forked your PR and pushed this fix to the infinite loop bestander@44d3c26 Let us know if you want to proceed with the PR feedback |
@bestander thanks for your involvement ! |
Thanks, I'll resubmit the PR on weekend
…On Fri, 17 Jan 2020 at 06:40, Nicolas Lunet ***@***.***> wrote:
@bestander <https://github.com/bestander> thanks for your involvement !
Since you probably have deeper knowledge of how yarn does its magic it
might indeed be better if you take care of the PR feedback !
Thanks !
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#379?email_source=notifications&email_token=AAQF2WD2EHKZQ2XNEUS22DLQ6G7PLA5CNFSM4IHB3Q52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJH4HJY#issuecomment-575652775>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQF2WCXUZZZRVDI5PNTW7TQ6G7PLANCNFSM4IHB3Q5Q>
.
|
Apologies, everyone. |
Ping! Would love to see this merged soon! Thanks for making it happen! |
Closing since the feedback wasn't addressed and it seems @bestander will simply create a new one. |
Fixes #300
This PR changes the way yarn bundling is being done.
The main thing to consider is that
yarn list
is nowhere close to whatnpm ls
does so you cannot really rely on that for bundling, especially in a workspace context.Instead the code goes through the dependency based on the node resolution algorithm https://nodejs.org/api/modules.html#modules_all_together
At package time this means we might end up with path like "../../../node_modules" which obviously do not make sense in a packaged environment, so those path are stripped to just be node_modules ...