Yarn: Analog to npm's --prefix command

[ttravers17]

In certain scenarios it is useful to be able to run npm from a seperate directory. With npm I can install node_modules from the root directory to the build directory. npm --prefix ./build install

Is there an analogous command for yarn?

[jamiebuilds]

A better flag name for this might be --cwd

[nsgundy]

Would like to install production dependencies to a different folder than the dev-dependencies. So a --prefix would be very helpful. Same goes for a --development switch (the other side of --production).

[nsgundy]

Seems like there is already a command switch for this: --modules-folder <path>. Strangely running yarn install --production --modules-folder production only works if there is no node_modules folder with the same files already.

[mattwellss]

@nsgundy the Yarn v0.18.1 help documents --modules-folder like so:

--modules-folder <path>     rather than installing modules into the node_modules folder relative to the cwd, output them here

That's not really what the same as --prefix does, which effectively switches npm's (or hopefully yarn's!) working directory to the argument passed to --prefix.

Currently this is blocking our migration away from both npm and bower, as a build script depends on switching the cwd with --prefix.

[reconbot]

@mattwellss hit's it spot on. Not only is it not the same, but it removes packages from your usual node_modules as well! As a workaround I'm copying the package.json and yarn.lock into my build directory, installing and then removing them.

[arcanis]

Currently this is blocking our migration away from both npm and bower, as a build script depends on switching the cwd with --prefix.

What's wrong with (cd /path/to/folder && yarn)? It seems more unix-y this way.

[Congelli501]

I generally try not to change directory in my bash scripts.
The problem is that you need to add a lot of code to just make a yarn install and go back to the previous state. From a developer POV, the cwd is a global state, and I prefer to pass it as an argument than keeping it global. You may also move code and forget a "cd ..", breaking further and unrelated parts of your script.

cd subdir
yarn install
cd ..

Most commands, even those relying on the cwd a lot have a way to pass the working directory as an argument, like git -C ~/foo status, npm --prefix install, composer --working-dir install, tar --directory...

[mfb]

This option would allow yarn to be a drop-in replacement for npm in build scripts. And if we want to bikeshed, I'd agree that gulp --cwd flag (and also composer's --working-dir flag) was more clear to me than npm --prefix flag

[milenvoutchev]

Yarn is indeed widely presented as (quote) "... a new package manager that replaces the existing workflow for the npm".
Striving to do that (replace the existing workflow), I believe many people would be expecting of Yarn to support the existing functions of npm and more. I know I did.

[BYK]

@arcanis Looks like Config class supports a custom cwd option anyways. Do you see any blockers to not do this and add a new CLI option, -C, --cwd to take this argument in?

[arcanis]

The main issue I have with a --cwd option is that they are somewhat ambiguous regarding where yarnrc files are read, even more so since we allow adding command line parameters from the yarnrc.

I haven't seen any answer to my previous post, could someone explain the advantages of such a flag versus (cd /path/to/folder && yarn), which doesn't suffer from the aforementioned ambiguity?

[milenvoutchev]

Readability. On the one hand it's yarn --option /path/to/folder.
On the other hand, it's cd path/to/folder && yarn && cd ../../..
Additionally, if the --prefix is adopted as option name, it will help for better compatibility as a drop-in replacement for npm.

[Zombaya]

cd path/to/folder && yarn && cd ../../ also has the downside that if yarn fails, you will not be in your original folder. (Although you can work around that by using ; instead of &&)

[saleemrashid]

@Zombaya You can use subshells for that (e.g. ( cd path/to/folder && yarn ))

[a7madgamal]

so... thats it?

[BYK]

@a7madgamal there's a --cwd option available now. See #4174 that was referenced above.

[corysimmons]

lol the downvotes to the guy suggesting "your-script": "cd dir; yarn start" <-- works and reduces tooling 👌

[reconbot]

Yeah but we don't always have easy access to cwd. Build scripts get complicated easily.

[corysimmons]

Also, if you care about variables in your package.json (for things like directories and such that might change (they probably won't)), then check out https://github.com/kentcdodds/nps (or even Makefiles)

[jcollum-autodesk]

lol the downvotes to the guy suggesting "your-script": "cd dir; yarn start" <-- works and reduces tooling 👌

I downvoted because there's an assumption that you will somehow automatically get back to the directory you started in. You can do that but you have to account for success and failure. Which means more complexity in scripts. My life would be easier if I didn't have to do that.

[atleta]

I downvoted because there's an assumption that you will somehow automatically get back to the directory you started in. You can do that but you have to account for success and failure.

I also missed at the first sight, but indeed the original suggestion above says (cd dir; yarn start). Note the parentheses, which will make the two commands run in a subshell. (So the cd will only affect the cwd of the subshell that will exit after running yarn and leave the cwd of your original shell unchanged.)

Doesn't matter anymore, and indeed some other unix command line tools do have this feature too (not to mention that this is a cross-platform one), just for the record.