No. The Yarn migration guide says Yarn Modern uses .yarnrc.yml and any other file is ignored, including .npmrc. If your registry URLs, scoped registries or tokens lived in .npmrc, they need converting. Missed settings can make installs fail, or fall back to a registry you did not intend.
What the guide says
The official step by step migration lists these steps: use Node 18 or newer, enable Corepack, set the version to berry, convert your .npmrc and .yarnrc files into .yarnrc.yml, run yarn install to migrate the lockfile, and commit. It warns that Modern uses YAML configuration, most keys are renamed, custom registries are configured with npmRegistryServer, and registry authentication tokens with npmAuthToken.
Note the ordering in that list. The lockfile migrates on the first install, so the configuration must be right before you run it, or the install resolves against whatever registry the new tool believes in.
Steps
- Inventory every setting in .npmrc and .yarnrc: default registry, scoped registries, auth tokens, proxies, certificates.
- Translate each into .yarnrc.yml using the settings reference.
- Keep tokens out of the repository. Use environment variable references or CI secrets, never a committed token.
- Run the first install on a branch, and read where packages were fetched from.
- Compare the new lockfile's versions with the old one (see verify resolved versions after switching package managers).
- Update CI for renamed flags and commands.
Renames that touch security checks
| Yarn Classic | Yarn Modern |
|---|---|
| yarn audit | yarn npm audit |
| install with frozen lockfile flag | the immutable flag |
| yarn install for production only | yarn workspaces focus for production |
| yarn global | yarn dlx |
The guide notes the frozen lockfile flag was renamed to immutable. A CI job that still passes the old flag may fail, or, worse, someone removes it to make the pipeline green and loses the guarantee. Also, the audit command moved, so a pipeline step that ran the old audit command needs updating. See frozen lockfile flags compared.
How to test the registry settings
Before trusting the migration, prove where packages come from. Run the first install with a clean cache on a branch, then look at the registry host recorded for each package in the new lockfile or in the install log. Every host should be one you expect. If a scoped package that should come from your private registry shows a public host, the scope setting did not carry over, and that is the exact condition that dependency confusion attacks depend on. Fix the setting, delete the cache and run again.
Scripts and bundled dependencies
Custom pre and post scripts for user scripts are no longer supported, while preinstall, install and postinstall remain. The guide also advises against bundleDependencies. Review any package that relied on it, and see Yarn Berry postinstall scripts off by default for the install script side.
Safeguard's dependency scanning and SBOM generation can inventory the project after the move, and the free scan at gold.safeguard.sh/scan is a quick check.
Quick check
Where do registry tokens go in Yarn Modern?
In .yarnrc.yml using npmAuthToken, ideally referencing an environment variable instead of a committed value.
Is the lockfile converted automatically?
Yes, on the first yarn install, per the migration guide. Check the result anyway.
Sources
Last reviewed: 19 October 2026.
