Yarn: Add package without saving to package.json

No, this feature was left out intentionally. It's considered dangerous to install a package without being reflected in the package.json. Why do you want such a thing to exist?

From the Facebook announcement

We removed the “invisible dependency” behavior of npm install and split the command. Running yarn add <name> is equivalent to running npm install --save <name>.

I use to used that feature pretty often to test things. Especially when I'm working with a library that I maintain and need to install a local version (which creates a file: dep) just to test out my changes before creating a release.

While I agree npm's implementation to do it by default was a poor choice, I think this is something that can come in handy when used explicitly.

Yeah I think allowing it to do with explicit flag would be nice to have, currently for this one can still use npm i =) but just to get rid of npm need.

We explicitly don't support this as it's an imperative change to node_module that would be wiped with subsequent yarn installs since we consider package.json and yarn.lock to be the source of truth.

We have a dependency that can't be installed easily on windows (libxslt) so:

• For windows: developers unzip it in their node_modues
• For linux: developers install it without save (if it's in package.json then developers using windows can't perform any install because build will fail)

Is there a clean way to do it using yarn (or any better way to achieve this result) ?

(I agree with you that packages should be reflected in the package.json though, but here I can't find any clean solution)

@GuillaumeLeclerc What about yarn add -D xxx and remove the entry from the package.json yourself?

It will be removed the next time another package is added ? Won't it ?

@GuillaumeLeclerc Unfortunately, yes.

@GuillaumeLeclerc You might want to clean up your comment...

Please add an argument like yarn add --no-save so that I can install a module without altering my package.json or yarn.lock. I often find myself needing to test modules before committing to them.

I can't use normal npm install because I get "Maximum call stack size exceeded". So yarn is the only viable way to install.

Please don't make me revert changes to package.json yarn.lock!

For me, this is biting me because I'm trying to install a peerDep. Yarn has no way to install peer deps during install so I have to manually do it. I can't yarn add <package> without having it get added to the package.json/yarn.lock. I'm stuck.

@viveleroi this sounds totally correct. Why would you want to install the peer dependency without adding it to your package.json?

@hpurmann Because it's duplicating my peerDependencies intodependencies (or devDependencies if I use --dev). If that's what's intended then it's certainly not intuitive.

@hpurmann I want to public a react component, so react shoulde be a peerDep. However, I need to install react in the project to develop it.

just add --no-save => it is so important
i need to skip a particular optional dependecy for a specific package. i can not do that with your yarn. may be with --no-save option i can work it arround

Because yarn link local-pkg does not install the dependencies of local-pkg in the host app I would like to install them directly but not save them to the app package.json since they will be brought by local-pkg once it is published.

I don't understand why the owners are so opinionated about this. If you don't see a usage of it doesn't mean there is none. I believe if people ask for it, it means they need it, and they are not necessarely stupid.
Adding a optional --no-save option would solve some people's problem and bring no drawback at all.

I'm trying to use Yarn for a NodeJS project that's run on AWS Lambda. I'm kindda surprised why this feature isn't supported. My use case is that I need to install aws-sdk on my local dev environment, but I don't want it to be saved in package.json because AWS Lambda already have this installed on their environment. Including aws-sdk means that our final package would be bloated.

yarn link and yarn add cannot live together. yarn add depends on package.json while yarn link just links the local packages over to another location.

Suppose you're developing a package X that depends on Y, you're both the developer of X and Y so you keep X and Y locally and link Y into the directory of X. When you do yarn add in X, it wipes out the link to Y.

How do you get around this?

~For such cases you could simply use the npm-commands to install without creating a footprint on package json or yarn.lock:~

~npm install [packages ...] --no-save --no-package-lock~

as @heikomat stated below, since npm5 uses auto-prune after install (see https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) this is not an option and could break your node_modules-folder completely.

ok so now I can't live without npm then

I was using npm install in one of my scripts that installs dependencies of local sub-modules to the main node_modules. This is working fine with npm4, but is completely broken with npm5, as npm5 just decides to nuke some packages during install -.- (see https://github.com/npm/npm/pull/18921)

For that reason, i was trying to replace the npm install in my script with yarn, but i can't really do that, if yarn always touches the package.jsons of the local submodules during installation, at least not without my script getting quiet messy and "cleaning up" after yarn

You already have --no-lockfile option, so it's makes node_modules folder out of think,
but devs still need to have workarounds to keep package.json immutable.

Thank you.

I like how every time someone explains their peculiar use case for installing a module but not recording it the maintainers come back in and recite their shibboleth. Must make it easy to feel confident in your obstinance if you can couch this same request from many different people as coming from those suffering from a moral failing. As a compromise, maybe we could name the switch --i-am-a-heritic-and-a-bad-programmer?

Sad to see the one key flaw yarn preserves from npm is its antagonism to anyone outside their organization.

And in my case I wanted to use it as a workaround for #4297 issue :)
Artificially limiting developers to do things might render your product unusable in certain situations.

Wait are you kidding me? This is a travesty. Please stop dictating how every developer workflow should work, ever. This is exactly why NPM didn't suit us and we moved to Yarn. This ideology that "package.json and yarn.lock should be source of truth" is nonsensical. Packages should be install-able without modifying the source code. Simple as that.

Come on, maintainers. It's obvious there's a real need for this by the community. Please stop shutting down intelligent conversation with unfiltered and misplaced philosophy.

Now I finding that yarn breaks my tests because I have modules where I need to test require and in order to test require I commit an example module into ./node_modules . Yarn is deleting the example modules when I run yarn install. More "source of truth" pedantry, I assume.

use case: Tool I use requires a package. Team doesn't use that tool. Team (justifiably) doesn't want that package installed.

This is seriously frustrating I use codelyzer for angular style guide, but the rest of my team does not and it has no affect on code functionality. The only way to get it to work now, is to add it to my yarn lock and just assume my yarn lock hasn't actually changed or to use npm even though my team uses yarn. Both of these are horrible options.

It's 2018 already but this feature hasn't been added yet despite the numerous valid use cases.

Just to give another example why this might be useful:

We have a script that automatically updates dependencies by installing the new version, running the tests and THEN saving it to the package.json/*.lock and committing that change OR rolling back if there was an error. It's way easier to just run yarn again instead of remembering the old version and explicitly adding that again.

Moreover it feels cleaner to not mutate your single point of truth (package.json) before "absolutely" being sure that you are able to really update this dependency without breaking a test. For now you end up with a package.json (even if it's temporarily) containing a dependency that breaks your code.

There are many valid use-cases for this issue. Would the yarnpkg maintainers be willing to accept a PR if one were to be created?

pinging @kittens if you are still affiliated with this project...

In the meantime, I use following script in the scripts section of package.json:

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

I assume there's an alternative for yarn?

There is no alternative, npm5 is messy as my life.

And don’t forget to copy symlinks in .bin folder. ;)

For me chmod 444 package.json and yarn add XXXX --no-lockfile at least works around the issue for local development and testing.
The add ends up with an (expected) permission error, but the added module is present in node_modules afterwards and I am able to test with peer dependencies locally installed but not persisted in the package.json but as peer dependency.

I sometimes require a debugging library temporarily, like why-is-node-running. I know I'll want to get rid of it after a single use, and a --no-save option would allow me to install-and-forget, without running the risk of polluting my dependencies.

I'm using Lerna, and I really just want to install _only_ Lerna in one of my CI steps, for the publish stage, as the project is already built in a previous step and artefacts carried over. Is that a valid scenario?

It would save me some steps, if this feature would be available.
My node_modules is in .gitignore anyways.

Instead of:

git clone external-package (needed for temp testing only)
yarn install
yarn link

go back to my original repo
yarn link external-package

just:
original-repo:
yarn install external-package --no-save

As part of our build pipelines, we need to install nsp and run it, exporting a dependency-check.xml.

I don't see why this simple tool install needs to be reflected in the package list, it just means I now need to do a git checkout ${BRANCH_NAME} to undo the modifications before I can push tags.

I'm not trying to modify the source. I don't want to and it isn't my business, that's up to the dev teams in my org. You're making my life a little bit harder for some abstract philosophy. Stop it.

Any idea, why this issue has been closed? Has the --no-save switch been added in a PR?

There are times I want to change a module's version that is brought in from a dependency. For example, @types/sinon brought in by another dev dependency recently broke my tsc. I don't want @types/sinon to my dev dependencies but I want to manually change the version with yarn add @types/[email protected] --no-save so I can keep working. Instead, I just switch back to npm. Super frustrating.

I have a production only dependency (appdynamics) that is very much a hack itself of platform-specific binaries. Turns out we don't even need it on the dev machines. Adding the yarn add ... --no-save would let us deploy cleanly without the script endangering the package.json (especially since package.json, obnoxiously, can't have comments explaining the purpose of each script or dependency)

cc @kittens @hpurmann

Please either address this incredibly popular issue or lock it as resolved. It would be highly appreciated to have a concrete answer in response to all of the criticisms raised above.

And community is ready to provide the feature, just let us know if you'd accept such pull request. Thank you.

haha, still not implemented, niiiiice

Why do you want such a thing to exist?

Was the exact same thing people said about JSX when it first came out mixing templates and logic. If it's possible and has its usecases, the correct question should be why not? I mean it's a flag, it's not default behaviour so you are telling yarn explicitely (aka I know what I'm doing).

@kittens @hpurmann
I have multiple packages in based on react and these have sub-module dependencies over one another. so I have react and react-dom as a peer-dep but when I need to build these packages individually I do need react and react-dom.
I guess this would be an apt use-case for installing packages locally without having them added as dep.
I would not like to have npm for such a trivial use in my project.
Any updates, waiting for something similar to --no-save.
I guess there is no harm adding a feature if the community demands, assuming the developer is aware of its side effects(loosing the local packages as soon as you run yarn install.)
Thanks

Handy trick is yarn add --dev pkg && yarn remove pkg. It does the same thing. THe lockfile stays as it was before that, so untouched.

This was mentioned by @Legends earlier but is worth emphasizing:

One workaround for some cases is to install the needed package in a separate folder and yarn link the needed package to wherever it would have otherwise been added. It's not ideal but can help.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb definitely not worth, imho. The add + remove is exactly what is done with the --no-save in npm. It does not mess with the system links and is not touching the lockfile in a bad way - meaning it's the same after the yarn remove.
Not to mention that if you want to do that thing programmatically then definitely creating dirs, linking and etc is not the way to go.

some cases

For example? Pretty weird ones for sure?

@hpurmann @kittens

So what is the recommended practice for developing a package with peer dependencies?

If I have e.g. React as a peerDependency in my package, should I add it as a devDependency as well in order to get imports resolved?

Looking at https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json I guess the answer is yes

@18steps check out https://www.npmjs.com/install-peers

There is some situations to use this feature.

Just like in CI lifecycle I added some coverage reporter. But I can't bring them to package.json then affects to publish NPM.

Save or no save, I think this choice should be up to the developers themselves not the tool.

Alright, let's try to look at this from the maintainers' perspective. I can definitely see downsides to a naive --no-save solution. We didn't get a very thorough explanation here, but I'll try to construct a steel man. Maybe they can correct me. Maybe we can find a compromise. @kittens @hpurmann

(Sorry, this ended up longer than I intended.)

Dependency management for modern Node- and web-applications is a bit chaotic. And yet, we want a system that gives us both reliable automation and a certain level of control and predictability, with features like deduplication and reproducible builds.

To get a handle on the complexity, we need to know what's installed and why, and we need a single source of truth to resolve any inconsistency. At the risk of stating the obvious, node_modules itself can't fulfil either of those roles. It's too slow to traverse, too large to transmit, too fine-grained to version-control, and it can't encode the 'why' aspect. That's why we have package.json and yarn.lock.

Yarn encapsulates the complexity of node_modules by giving us restricted access through an interface. If we promise not to break encapsulation, we get certain guarantees in return, like deduplication and reproducible builds. If we install things in node_modules without a corresponding change in package.json and yarn.lock, we lose those guarantees.

Moreover, that's an unspoken contract that many developers aren't explicitly aware of. When they break it, they don't do so knowingly. So when things go wrong, Yarn may be unfairly blamed. Plus, making a tool that's difficult to shoot yourself in the foot with is not a bad design philosophy.

However, I can see several reasons to compromise:

• There seems to be a definite need here. Just look at the many use-cases listed in comments above, and the 'thumbs up' / 'thumbs down' ratios. The maintainers' apparent stubbornness in the face of such a one-sided response doesn't make Yarn look too good.

• There are solutions to be found that may work for everyone. For example, introduce a new file yarn.local.lock. Developers would put it in their .gitignore, and it would keep a record of all packages installed with the --no-save flag and their dependencies.

  In order to keep yarn.lock isolated from this, deduplication and flattening of the 'local' dependency tree is restricted. The local lock file may adapt to match a version in the main lock file (and dedupe in that case) but not the other way around. As a result, many transitive local dependencies might not be flattened into node_modules.

  With this solution, Yarn can continue to keep track of all packages, developers are able to install stuff without polluting their repo, and we preserve reproducible builds. (There is also room for a package.local.json with a devDependencies section, but I'm not sure it would be required.)

• People are already using workarounds to get what they want anyway, at least three of them described in comments above. But they are inconvenient to use, don't offer the same guarantees and require that developers fight against Yarn to figure them out. It's the worst of both worlds.

I might have missed something, but this seems like a conversation worth having.

I have another use case: I'd like a module to be available in REPL but don't intend to use it in my code. As it stands I need to go into a different folder and install that module there, then import some json files using ../other-project/data/xyz.json.

But if I want to import a module and that thing imports other modules using relative paths, well, it's gonna break.

Just letting me install a module into node_modules without saving would make it all a lot easier.

I'm surprised how resistant the maintainers are to this idea.

Goodness me, I just read through the previous comments and the attitude from the maintainers is disappointing. I develop many framework specific plugins which have dependencies on framework libraries and I want to avoid adding those as hard dependencies into my plugins.

I have a plugin which relies on specific packages defined in peerDependencies, now the issue like many other people have already commented is, how the heck do you install the dependencies locally without adding them into the package.json file? Well, you can't.

The only solution I have found is installing the peerDepencies as devDependencies which doesn't feel ideal at all, but it works around the problem. At least npm in its horrible state installs without modifying your package.json file.

@hpurmann @kittens

Have you given up on responding to the community? Clearly, ignoring this issue isn't doing you any favours and it's not going away. What's the point of calling this an open source project if you're not even going to answer the simple question of if someone does the work and submits a PR, will you accept it?

I probably should have answered some time ago, right after @viveleroi explained his quite valid use case (which a lot of you seem to have). Back then I did thumbs up his response, which is obviously not enough to get noted.

I changed my mind. Usually, people want a lot of things and if the maintainers are accepting every feature, the software becomes bloated. I don't have this use case but I see many people wanting it.

I can't decide anything though. I'm not a maintainer of this project.

@Vheissu What is the issue with yarn add --peer <dep>?

for me yarn add --peer works UNTIL you add another package, at which point the existing peer deps are removed from the local install and you have to manually readd them.

I would like this feature because today because I am writing an example implementation of my library using express, but none of my code depends directly on express. I don't want anything to install or depend on Express, but I do want to install it into my current directory.

Just like @brendan-hurley @suyanhanx, I have dependencies that I want to install in CI and not locally.
I want to keep my local dependencies at a minimum so that we don't have to bloat up node_modules and cost us time and space for every developer working on the project.

Packages that are needed in CI but not locally:

• CI specific tools: semantic-release, greenkeeper-lockfile
• Coverage reporting tools: codacy-coverage, coveralls
• Test reporting tool for CI: jest-junit, etc.

Here is why we need this feature:

Using yarn link wont link the dependencies of the package over, so you need to install them in
the linked destination - having these external dependencies added to package.json just makes it so much inconvenient.

Either yarn link has to add dependencies or provide a way of excluding the in destination package.json

I have a pretty esoteric use case, but this would be helpful for me. I fully understand why it's important for yarn.lock and package.json to be the source of truth, and that if I used a --no-save command, my changes would be wiped out on subsequent yarn commands.

That said, I wish that yarn would trust me to know what I'm doing and allow me to pass the --no-save flag. If I run into any of the problem cases, I'll know exactly what went wrong, and that I only have myself to blame. :smile:

My use case?
I run a 64-bit win machine.
Prod machine is 32-bit.

Node-sass dependency we have only supports 32-bit unless we update the package.

Not changing the dependency in the package.json or yarn.lock to support a dev machine.
So would like to locally install the latest node-sass to support 64-bit, but not affect the package.json and yarn.lock

I'd like to install @types/* packages to non-TypeScript projects without tainting package.json / yarn.lock for better autocompletion in VSCode.

I use lerna with yarn workspace.
Antd's type definition breaks due to @types/[email protected] update.
Antd will fix this at weekend.
But now I need to force the yarn to install a fixed version of @types/[email protected] into workspaceRoot manually without affect the current package.json(since it will install the latest version automatically).

Keeping the default behavior of saving to package.json is right, but there are real cases that developer must install the module without affect the package.json. Especially when there are some unexpected breaking change in some packages.

Implicitly updating package and implicitly saving to package.json lead to conflict.

Here's another use case. I maintain a React library. Before publishing a new version, I want to run my tests against several versions of react and react-dom, to verify that my changes are backwards and forwards (@next) compatible. I was doing this using the setup below, but now I want to use Yarn's workspaces so I need to migrate to Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react@next react-dom@next --no-save && npm test",
"test:latest": "npm i react@latest react-dom@latest --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

I can't have this script change my package.json as that would make my publish command (pack publish) fail due to unstaged changes.

I want to add additional packages in my CI pipeline for testing purposes without touching the package.json file (might be a readonly file mount).
These are not part of the dev components.
During development and testing on the dev machines, they shall not be installed and during build and prod they shall not be installed, they are only ever necessary and acceptable on the CI server during tests.

This works by just using npm, but yarn should be able to remove the depency upon npm.
This very well might bring us back to using npm only instead of yarn only.

Also it just breaks the promise of yarn being able to completely replace npm, because it just can't do what npm can.

Also yes absolutely hide this feature behind some flag because this shouldn't be a normal use case but an edge use case.

are you kidding ? 3 years to add a simple switch ?

Another use case: We use a npm package (git-hoooks) for pre-commit checks. Not everyone on the team has node installed, so including it in package.json would break commits for some people. So I'm trying to create npm scripts to transiently enable/disable hooks by installing/removing git-hooks. Very disappointed to find out this seemingly simple & easy task is virtually impossible to accomplish with yarn.

If the worry is that yarn.lock will no longer be a source of truth for the contents of node_modules, well, what's so bad about that? Couldn't existing functions simply ignore the existence of the untracked dependencies? Yarn is a great tool and the maintainers have done a great service to the JS community, but they need to reconsider this decision.

are you kidding ? 3 years to add a simple switch ?

@spanasik and @Ryuurock: please be polite when discussing high-quality software that's provided to you for free.

This hasn't taken "3 years" because the switch is too complicated to implement – it's because the maintainers remain unconvinced that it'll be a net benefit for users. If you disagree with this, make an argument for the feature.

@NickHeiner here are 10 screens of arguments. And the main thing that drives frustration, is not that maintainers unconvinced, but that they're ignoring it, don't reply to arguments, when people "disagree with this, make an argument for the feature". And when people frustrated, of course they leave unpleasant comments. Please don't blame the whole thing on users.

I agree that it would be better if the maintainers would address the discussion here. There's clearly interest from a broad set of people across several years. So perhaps my suggestion that @spanasik and @Ryuurock should just "make an argument" is unreasonable, because it would likely be ignored like everything else here.

And when people frustrated, of course they leave unpleasant comments. Please don't blame the whole thing on users.

I disagree. This rudeness is still not a useful step forward, nor acceptable behavior among adults. Being impolite is a great way to justify the maintainers ignoring this further: "the thread is just trolls".

Constructive ways to move forward:

1. Draw maintainer's attention to this thread on other channels (maybe they've ignored it) and ask them to at least acknowledge the arguments here, even if they don't agree.
2. Fork / replace yarn and govern the project in a way people are happier with.

Handy trick is yarn add --dev pkg && yarn remove pkg. It does the same thing. THe lockfile stays as it was before that, so untouched.

Tested - does not work.

My use case is the following:
Some packages have optional addins that is loaded with 'require'. I do not want to add these add-ins to the devDependencies section so I do a 'yarn add my-add-in' and remove it manually out of the package.json file. On my cloud CI pipeline I use 'npm i' add them (for testing). On my local pipeline I do not want to use npm because it create an extra lock file. My best option now is to use npm and then delete their lock file (to remove the appearing second version of the truth).

So after reading everything my question to the maintainers are this:

• Why are you so inconsistent?
• Why not implement this philosophy right through every feature?
  
  
  
  • That is: Decide how things should be done for all of us and remove all other options from all features. Stay the course! Stay true to yourself!
  
  

The undeniable fact is that all good software have config settings because good software will allow the user to choose what is best for his situation. And to always touch the 'package.json' file is good practice - but there exist edge cases where 'yarn' is just not up to the task because of this philosophy.

I really like yarn because its simple and fast. It is really unfortunate that the maintainers are fighting a battle they are sure to loose - because the community is forced to revert back to slow reliable npm in order to make things work.

Let’s turn down the temperature a bit. No one need feel disgusted by a
piece of software they’re allowed to use for free.

On Wed, Jan 15, 2020 at 23:17 Hajime Yamasaki Vukelic <
[email protected]> wrote:

I feel disgusted that yarn makes me work in a certain way. I like to
decide things on my own, and I don't like it when my tools tell me how I
should work, insult to my intelligence being the least of the problems, and
not being able to get things done being by far the biggest.

To believe in perfect rules and that there would never be an occasion to
break them is naive. There's a difference between "best practices" and
"do-or-die". As Oliver Wendell Holmes Sr. puts it:

The young man knows the rules, but the old man knows the exceptions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJDBE4Q#issuecomment-575017586,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Make your own package manager, no-one's making you do anything.

Not angry at all, just pointing out the error in your logic:

yarn makes me work in a certain way.

Yarn isn't making you do anything, they've made a tool (for free) and it works in a certain way. If you don't like it use something else.

@foxbunny I appreciate you clarifying your disgust. :)

Even if you believe that it’s reasonable and just to feel disgusted in this case, I don’t think that language is a polite way to talk to the people who have built this freely-available tool for you. You can give constructive feedback while still being respectful.

@whitecolor the team has got a point. That option --save is stupid. Yarn guaranties equilibre between node_modules, package.json and the lock file and that's great. That's safer .... the npm --save is dangerous. It let me down many times

Please STOP IT

Or how about everyone just use the tool that works the way they think is better and calm down.

My use case is

I want to update sub-dependency of our app
I link this dependency with yarn link
I then use linked one in our app
I add some dependency in our library
Added lib dependency is not installed in the main app after yarn install (wtf no.1)
Then I think, ok, let's just add it quickly without saving to the app so I can just check if stuff works before I publish update to our lib
But - nope.

Thanks

Sorry to see the community ignored by the authors.

As an open source volunteer, one needs to have a coherent philosophy or the
project will degrade into a ball of mud. This means sometimes telling
people “no”. If you disagree, you’re welcome to make your own package
manager, just like yarn replaced npm.

On Tue, Mar 3, 2020 at 03:53 Artur Kwiatkowski notifications@github.com
wrote:

Sorry to see the community ignored by the authors.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENTGKUY#issuecomment-593913171,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

I'm using Lerna, and I really just want to install _only_ Lerna in one of my CI steps, for the publish stage, as the project is already built in a previous step and artefacts carried over. Is that a valid scenario?

^ my original comment - I honestly don't know why I'd ever need this, and I didn't know this thread would blow up so horribly - but it's amusing to see emails about it years on.

I'm inclined to agree with the maintainers here:

1. I'm unconvinced by my own argument. I guess the maintainers were being polite by not calling it out for being a stupid argument.
2. Even if someone _does_ raise a PR, it would mean that ongoing maintenance of the feature would be the further burden the maintainers, blocking them from maintaining the core product.
3. This kind of feature would be misused by unassuming newbies and/or otherwise relatively unskilled consumers of yarn, further perpetuating point 2.

In any case there's probably a better, more architecturally sound way to mitigate against the need for this feature.

I created yarn-add-no-save to achieve this functionality. It can be installed local to your project or globally:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

Once installed you can simply run:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

My use case is to test modules that declare peerDependencies so the tool has some options to automatically install them, to see all the options run:

$yarn add-no-save --help

NOTE: I am aware that saving a package to install packages without saving them is ironic and basically defeats the purpose, but this is the best I could come up with and it fits my needs.

This is very helpful, especially peerDeps support. Thank you.

There are several good arguments for this feature. It's not like doing it the default, people is asking for it to be behind a clear flag that only people in need for it will use it. Currently, like some other, I need to do some testing during CI with other library versions that I don't want to save. I can't understand what is so hard to understand here.

I have to yarn install xxx then yarn remove xxx.

Not sure if this usecase was ever discussed . Let me try to explain my situation - I have bunch of packages interdependent on one another in one repo. They all use the same external dependencies with a common package at root servicing sub projects underneath, each local package needs to be built in the order for the next to consume. I am trying to use yarn workspaces for this. To start I don’t have any local packages defined in my root package.json. After one full cycle of building all components, I end up having a fully updated root package.json with those local dependencies . Now when this updated one gets built on CI- all those local packages added are going to fail due to non availability. We have to remove those newly added entries to make it work in CI.

I have to yarn install xxx then yarn remove xxx.

the same

Here's a use case for wanting to be able to do this:

We're building a tool with a modular ecosystem for "appliances" within the tool, and the plan is for a local instance to be set up with those appliances, and have them activated dynamically via configuration. The appliances are published to npm (and could be invoked outside of our framework if someone wanted).

The vanilla project does NOT depend on these packages, so saving to package.json would be inappropriate. A specific instance's configuration might call for one of the packages to be installed locally.

Lacking this feature seems to be a limiting decision for our project, though we'll continue to explore alternative approaches.

Before I read "maintainers" reply here, I thought I was the most stubborn person ever.

Almost 4 years... 🤦

"Stubbornness" is not the same as "having a design vision and not implementing everything anyone asks for".

"Stubbornness" is not the same as "having a design vision and not implementing everything anyone asks for".

Design vision describes happy path, and escape hatches as the one requested here, add to the usefulness for the wider community.

Why not just add a section to the lock file that keeps track of "freeform" installs, and incremental snapshots of the status quo (in node_modules), to make those safely reversible? Or maybe put dependencies in a folder separate from node_modules, and use node_modules just to keep links exposed to its package, so Yarn can actually manage stuff on its own and not worry about invisible installs overwriting and breaking stuff.

Git solved this problem decades before you, catch up! Just come up with something! That is what design is - circumventing limitations, rather than fighting them (or yielding to them).

The tunnel vision in both ends here is born of ignorance, overthinking, and needless polarization. There's no martial arts or philosophy or revolution or politics; there's just a tool, a bunch of code, and a job to be done. If the tool can't help get the job done, it is not a tool for that particular scenario. And for a tool purporting to be a general-purpose full on replacement, like Yarn is, there are so many common scenarios being neglected here that it's simply digging its own grave.

I feel like everybody's pushing against each other up a narrow hill when we could just go around it.