-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix yarn global prefix directory #3721
Conversation
src/cli/commands/global.js
Outdated
|
||
return prefix; | ||
try { | ||
await fs.access(path.join(POSIX_GLOBAL_PREFIX, 'bin'), nativeFs.constants.W_OK); |
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.
This fs.access
call can be memoized by adding the following line after it:
await config.registries.yarn.saveHomeConfig({prefix: POSIX_GLOBAL_PREFIX});
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 not use the same fs.access
path for Windows too?
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.
If you want to ensure if we have permission to write to %LOCALAPPDATA%\Yarn
, that can be done. It's likely redundant though, because it's almost guaranteed to be writable, at least as writable as ~/.yarn
(FALLBACK_GLOBAL_PREFIX
).
I guess it won't hurt to do that.
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.
Left some comments here: #2064 (comment)
src/cli/commands/global.js
Outdated
|
||
return prefix; | ||
try { | ||
await fs.access(path.join(POSIX_GLOBAL_PREFIX, 'bin'), nativeFs.constants.W_OK); |
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 not use the same fs.access
path for Windows too?
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.
Overall looks good. Just have questions about compatibility with Node and "doing the right thing" :)
if (process.env.LOCALAPPDATA) { | ||
return path.join(process.env.LOCALAPPDATA, 'Yarn', 'bin'); | ||
prefix = path.join(process.env.LOCALAPPDATA, 'Yarn'); |
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.
Let's make this yarn
as we are at it, instead of the upper-cased Yarn
?
@Daniel15 @bestander any reason we were using Yarn
?
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.
@BYK The standard on Windows is to use uppercase. If you take a look in %LocalAppData%
you'll see that most folders are uppercase. Some badly-behaved apps use lowercase, but it's not the norm.
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.
Alright, NVM my comment then. Yarn should be a nice kitty.
@@ -59,6 +59,9 @@ export const CONFIG_DIRECTORY = getDirectory('config'); | |||
export const LINK_REGISTRY_DIRECTORY = path.join(CONFIG_DIRECTORY, 'link'); | |||
export const GLOBAL_MODULE_DIRECTORY = path.join(CONFIG_DIRECTORY, 'global'); | |||
|
|||
export const POSIX_GLOBAL_PREFIX = '/usr/local'; |
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.
May be we should do path.dirname('path/to/node')
as suggested in https://docs.npmjs.com/files/folders#prefix-configuration ?
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.
Perhaps we should try both. /usr/local
is good if it's writable by the user, otherwise the directory that Node.js is installed from (I think there's some property on process
that has the full path of the Node.js process?)
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.
From what I understand from NPM docs, we should to this in the opposite order: try node
s folder first. That said not sure how well it would play with homebrew or my local folder hacks (I alias node
to ~/Desktop/node8
etc. for quick testing purposes and I heard this is not that uncommon)
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.
@BYK Implementing NPM's behavior of using parent directories of the node executable will come with bugs, I've described this in #3458 and #2064 (comment).
Daniel also said something similar:
The issue is that Yarn symlinks the executables into the wrong directory (the Node.js directory rather than somewhere reasonable). It doesn't really make sense to use the Node.js directory for these scripts, and on many systems that directory is not even writable by regular users.
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.
@KishanBagaria - oh okay. Sorry I got lost in those long conversations. Thanks a lot for clarifying!
Shall we put this into the code as a 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.
No worries, the whole global-prefix thingy has been a quite long conversation indeed.
Maybe the website docs can be updated with how we get the prefix so that regular users can find the info easily, and why we don't mimic NPM.
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.
Maybe the website docs can be updated with how we get the prefix so that regular users can find the info easily, and why we don't mimic NPM.
I think this is a great idea! @Daniel15 any suggestions? I can file an issue for this so we don't forget.
Also this patch needs a rebase to get the tests passing on CI again. |
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.
👍 for now but I'd like to talk more about https://github.com/yarnpkg/yarn/pull/3721/files#r127006212 //cc @Daniel15 @KishanBagaria
* Fix: Make sure global prefix folder is writeable when selecting it **Summary** Fixes #4320 and fixes #4323. We were using `fs.access` when selecting the global prefix folder automatically which only checks for permissions but not actual writeability. This caused issues on Heroku where one of our first tries had the correct permissions but was on a read-only file system. **Test plan** Existing cache folder fallback tests should be enough for now. We should move the core of those tests for the newly added `fs.getFirstWriteableFolder` method. * Fix wrong error message template used from getGlobalPrefix * Better error message * Add process.execPath as a last resort * Add back $DESTDIR support removed from #3721 * Fix DESTDIR typo * Fix skippedFolder error * don't use rimraf to remove a file * Don't use process.execPath * Defer write checks for global prefix * flow type * Just warn when a proper global folder cannot be found, instead of failing * Add TODO about inconsistent npm-registry code * Keep the old behavior * Update fs.js
) * Fix: Make sure global prefix folder is writeable when selecting it **Summary** Fixes yarnpkg#4320 and fixes yarnpkg#4323. We were using `fs.access` when selecting the global prefix folder automatically which only checks for permissions but not actual writeability. This caused issues on Heroku where one of our first tries had the correct permissions but was on a read-only file system. **Test plan** Existing cache folder fallback tests should be enough for now. We should move the core of those tests for the newly added `fs.getFirstWriteableFolder` method. * Fix wrong error message template used from getGlobalPrefix * Better error message * Add process.execPath as a last resort * Add back $DESTDIR support removed from yarnpkg#3721 * Fix DESTDIR typo * Fix skippedFolder error * don't use rimraf to remove a file * Don't use process.execPath * Defer write checks for global prefix * flow type * Just warn when a proper global folder cannot be found, instead of failing * Add TODO about inconsistent npm-registry code * Keep the old behavior * Update fs.js
Previous PR: #3458
Fixes: #2064