Add package without saving to package.json

[wclr]

It seem there is no possibility to install package using yarn without touching package.json? (like npm install without --save params). Shouldn't such feature be added?

[hpurmann]

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>.

[reallistic]

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.

[wclr]

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.

[sebmck]

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.

[GuillaumeLeclerc]

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)

[jorgebucaran]

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

[GuillaumeLeclerc]

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

[jorgebucaran]

@GuillaumeLeclerc Unfortunately, yes.

[reallistic]

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

[themadcreator]

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!

[viveleroi]

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.

[hpurmann]

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

[viveleroi]

@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.

[loadingwyn]

@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.

[khalid-elabbadi]

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

[kavi87]

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.

[OoDeLally]

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.

[simoncpu]

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.

[namgk]

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?

[PutziSan]

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 npm/npm#16853 + npm/npm#18921) this is not an option and could break your node_modules-folder completely.

[namgk]

ok so now I can't live without npm then

[heikomat]

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 npm/npm#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

[alexindigo]

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.

[bigeasy]

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.

[alexindigo]

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.

[Qix-]

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.

[ghost]

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.

[ghost]

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.

[NickHeiner]

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 < ***@***.***> 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 <#1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJDBE4Q#issuecomment-575017586>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA> .

[leonaves]

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

[leonaves]

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.

[NickHeiner]

@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.

[khalid-elabbadi]

@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

[leonaves]

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

[pie6k]

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

[frontendbuddy]

Sorry to see the community ignored by the authors.

[NickHeiner]

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 ***@***.***> 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 <#1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENTGKUY#issuecomment-593913171>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA> .

[brendan-hurley]

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.

[darionco]

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.

[alexindigo]

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

[danielo515]

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.

[FrankFang]

I have to yarn install xxx then yarn remove xxx.

[callramesh]

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.

[slifty]

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.

[seelts]

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

Almost 4 years... 🤦

[NickHeiner]

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

[alexindigo]

"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.

[wallabra]

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.

[cefn]

The below entries in my package.json have been a short-term workaround for my case - developing a React library.

It means the yarn test command can be provided with temporary copies of test dependencies for the duration of the test script.

    "pretest": "yarn add --dev react",
    "posttest": "yarn remove react; yarn add --peer react",
    "test": "jest"

Performing local tests is the only circumstances a package is (temporarily) needed. In all other cases it should be provided by the (singleton) version of react within the user's own repo. Basically the react package is required as a peerDependency to flag to users, but must not be either a dependency or a devDependency as this breaks React in production at runtime. This of course means you can't run any tests within your package which have a react dependency!

See https://reactjs.org/warnings/invalid-hook-call-warning.html#duplicate-react for the runtime error which react apps hit when react is either a dependency or devDependency of any imported library. That webpage hopefully explains how the opinonated feature-omissions from yarn add impact react library developers specifically. Perhaps a few contributors to this thread are developers of React libraries?

[cefn]

Actually after a bit more experimentation, while this leaves the package.json in a good state to be committed, it still messes with the local node_modules in a way which interferes with bundling, causing the tested package to have its own copy of react after running tests and therefore bundling it incorrectly and creating the React error linked above.

That's because as far as I can see there's no way to use the yarn cli to add back a peer dependency without actually installing it. So finally my package.json has these as a workaround instead...

    "pretest": "npm install react --no-save",
    "posttest": "npm uninstall react; rm package-lock.json",
    "test": "jest",