Skip to content
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

Add package without saving to package.json #1743

Closed
wclr opened this issue Nov 9, 2016 · 98 comments
Closed

Add package without saving to package.json #1743

wclr opened this issue Nov 9, 2016 · 98 comments

Comments

@wclr
Copy link
Contributor

wclr commented Nov 9, 2016

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
Copy link
Contributor

hpurmann commented Nov 9, 2016

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
Copy link

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
Copy link
Contributor Author

wclr commented Nov 9, 2016

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
Copy link
Contributor

sebmck commented Nov 10, 2016

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
Copy link

GuillaumeLeclerc commented Nov 21, 2016

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
Copy link

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

@GuillaumeLeclerc
Copy link

GuillaumeLeclerc commented Feb 8, 2017 via email

@jorgebucaran
Copy link

@GuillaumeLeclerc Unfortunately, yes.

@reallistic
Copy link

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

@themadcreator
Copy link

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
Copy link

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
Copy link
Contributor

hpurmann commented Sep 7, 2017

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

@viveleroi
Copy link

@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
Copy link

@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
Copy link

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
Copy link

kavi87 commented Sep 25, 2017

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
Copy link

OoDeLally commented Oct 9, 2017

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
Copy link

simoncpu commented Oct 20, 2017

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
Copy link

namgk commented Oct 23, 2017

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
Copy link

PutziSan commented Oct 30, 2017

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
Copy link

namgk commented Oct 30, 2017

ok so now I can't live without npm then

@heikomat
Copy link

heikomat commented Nov 2, 2017

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
Copy link

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
Copy link

bigeasy commented Dec 25, 2017

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
Copy link

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-
Copy link

Qix- commented Jan 8, 2018

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
Copy link

ghost commented Jan 5, 2020

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
Copy link

ghost commented Jan 5, 2020

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
Copy link

NickHeiner commented Jan 16, 2020 via email

@leonaves
Copy link

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

@leonaves
Copy link

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
Copy link

@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
Copy link

@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
Copy link

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

@pie6k
Copy link

pie6k commented Feb 17, 2020

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
Copy link

Sorry to see the community ignored by the authors.

@NickHeiner
Copy link

NickHeiner commented Mar 3, 2020 via email

@brendan-hurley
Copy link

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
Copy link

darionco commented Apr 26, 2020

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
Copy link

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

@danielo515
Copy link

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
Copy link

I have to yarn install xxx then yarn remove xxx.

@callramesh
Copy link

callramesh commented May 12, 2020

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.

@ethanyou725

This comment has been minimized.

@slifty
Copy link

slifty commented Jun 15, 2020

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
Copy link

seelts commented Jun 18, 2020

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

Almost 4 years... 🤦

@NickHeiner
Copy link

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

@alexindigo
Copy link

"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
Copy link

wallabra commented Jul 26, 2020

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
Copy link

cefn commented Feb 20, 2021

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
Copy link

cefn commented Feb 20, 2021

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

@yarnpkg yarnpkg locked as too heated and limited conversation to collaborators Feb 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests