Configure --legacy-peer-deps with .npmrc

[kentcdodds]

I'd love it if I could configure npm (globally and per project) with the --legacy-peer-deps functionality. This is especially helpful when using dependencies whose maintainers are no longer active but their projects support versions of peerDeps that are outside the version range specified.

Proposed config name: legacyPeerDeps and it could be a Boolean.

This could be in wherever .npmrc files typically go and npm would respect those values like it does with everything else.

[darcyclarke]

@kentcdodds Hey Kent! This should already be possible with setting the legacy-peer-deps config (ref. https://docs.npmjs.com/cli/v7/using-npm/config#legacy-peer-deps). You can define it as a boolean in your local project or global .npmrc file by running npm config set legacy-peer-deps true with an optional -g to set it globally.

[ljharb]

(note that lts/gallium describes node, being on a node version doesn't guarantee you're on any particular npm version)

[ryders]

Hi folks, sorry to be reviving an old thread. We use CI/CD to automatically deploy to feature environments and I just came across this after someone in our team installed a npm package locally with --legacy-peer-deps... as you can assume this change automatically failed deployment, and it seems this solution works.

However, I'm not sure that I'm ok with just accepting all "legacy / unmaintained" packages moving forward and I'm curious to hear your approach on how to best manage our app integrity and package versions.

Q1. Would it not make sense for --legacy-peer-deps to have some value (other than boolean) in order to formally allow certain packages through, but not all?

Q2. is your preferred "best practice" to (a) always allow all updates (which will generally create some problems with packages not maintained regularly enough) or (b) lock all packages version and perform monthly or quarterly or yearly "upgrades"

@darcyclarke curious to here your thoughts mate.

Any reading material welcome.

[ljharb]

In general, I'd suggest not allowing any dependency that requires the flag - since that means your dep graph is invalid.

The only reliable way to keep your dep graph valid is to enforce that it remains so, by never using the legacy flag.

[ryders]

thank @ljharb -- am very much i agreement with that. It does mean however that any upgrades may yield packages that need to be replaced and/or wait until the maintainer also upgrades, right? The only way to avoid this would be for our team to

• fix package+send pull request hoping for action
• fork + fix and use "our" version of the package
• use a different library an possibly refactor code

right?

[ljharb]

Yes, exactly right.

[hippo-guy]

I just ran the command npm config set legacy-peer-deps=true and it changed the global file instead. Is this expected?

[ljharb]

It should change ~/.npmrc, and yes that's expected.

[ruyadorno]

there's a location option that can be used to specify changing the project .npmrc instead, e.g:

npm config --location=project set legacy-peer-deps=true

ref: https://docs.npmjs.com/cli/v9/commands/npm-config#location

[GirijaHegdeGit]

npm config set legacy-peer-deps true : what happens if I run this command

[entranced]

It will add legacy-peer-deps=true to your .npmrc file.