@yarnpkg/doctor

@yarnpkg/doctor

A cli tool to help package maintainers support pnp.

Usage

To check your package run:

yarn dlx @yarnpkg/doctor ./package-dir

You'll get a pretty output with all the warnings.

Rules

• no unlisted dependencies
• no unmet peer dependencies
• no node_module strings
• no unqualified webpack loaders
• no bundleDependencies

no unlisted dependencies

This rule warns when imported dependencies are not listed in a project/workspace's package.json.

Node allows you to import any package without having a version specified in your package.json. This can lead to subtle and hard to solve bugs.

For example:

• Node might find a globally installed package and the project works on your machine. While other your colleagues might be missing the globally installed package or (worse) have an incompatible version installed.

• Or Node might find a transitive dependency (dependency of a dependency) and use that. If you remove or upgrade that dependency and it affects the transitive dependency then it can trigger all sorts of bugs.

By making sure all dependencies are listed in the package.json pnp can make your project less brittle.

no unmet peer dependencies

This rule warns when a package has unmet peer dependencies.

Peer dependencies are useful for allowing package authors to delegate control of a dependency's version to the package user. When used correctly they prevent version conflicts and reduce bundle sizes.

Peer dependencies must be manually added to the package user's package.json. Because they responsibility of the package user they can be overlooked.

This rule ensures that all peer dependencies are included and therefore installed for your project.

no node module strings

This rule warns when node_modules appears in strings or template literals.

If a string literal includes "node_modules" else it is likely a sign that the package is doing shady things with node_modules which would likely fail under PnP.

One of the big benefits of Plug-n-Play is that it does away with node_modules directories to achieve zero installs, increased stability and reliability. Therefore, resolutions that rely on the presence of a node_modules folder will fail.

Aside from satisfying Plug'n'Play requirements, resolving packages using node_modules this way is brittle and may result unpredictable packages versions and subtle bugs.

Examples of incorrect code for this rule:

var module = require("../node_modules/lodash");

Examples of correct code for this rule:

var foo = require("lodash"); // importing a module by its name

no unqualified webpack config

This rule disallows referencing loaders or plugins in string literals in a webpack.config.js in a non-private package.

Ensures that third party tools (CRA, Next, Vue-cli, etc) resolve their own versions of loaders and presets.

When loaders and plugins are included as strings e.g loader: 'file-loader' in a webpack.config.js then Webpack will try to resolve it from the point of view of the project root.

If the webpack config is located in a dependency, as with tools such as Create-React-App, Next.js and Gatsby, then Webpack might accidentally use an different hoisted version of a plugin. This can cause various weird bugs and crashes.

The third party tool should use require.resolve('file-loader') so that Webpack loads the plugin through an absolute path and it will use the loader/plugin it specifies in its own package.json.

Examples of incorrect code for this rule:

const webpackConfig = {
  use: `ts-loader`,
};

Examples of correct code for this rule:

const webpackConfig = {
  use: require.resolve(`ts-loader`),
};

This rule is a temporary measure to address this issue

no bundleDependencies

This rule warns when the bundleDependencies (or bundledDependencies) field is used.

Visit the dedicated section on the website to learn more.

Further reading

• Yarn 2 docs
• Introduction to plug-n-play

Changelog

3.0.0

Breaking Changes

• Node 10 isn't supported anymore.
• Plugins can't access yup anymore (we migrated to Typanion as part of Clipanion v3).
  • To upgrade workspace-tools, remove it from your .yarnrc.yml, upgrade, then import it back.
• The enableImmutableInstalls will now default to true on CI (we still recommend to explicitly use --immutable on the CLI).
  • You can re-allow mutations by adding YARN_ENABLE_IMMUTABLE_INSTALLS=false in your environment variables.
• The initVersion and initLicense configuration options have been removed. initFields should be used instead.
• Yarn will now generate .pnp.cjs files (instead of .pnp.js) when using PnP, regardless of what the type field inside the manifest is set to.
• The virtual folder (used to disambiguate peer dependencies) got renamed from $$virtual into __virtual__.
• The -a alias flag of yarn workspaces foreach got removed; use -A,--all instead, which is strictly the same.
• The old PnPify SDK folder (.vscode/pnpify) won't be cleaned up anymore.
• The --skip-builds flag from yarn install got renamed into --mode=skip-build.
• The bstatePath configuration option has been removed. The build state (.yarn/build-state.yml) has been moved into the install state (.yarn/install-state.gz)
• The cache files need to be regenerated. We had to change their timestamps in order to account for a flaw in the zip spec that was causing problems with some third-party tools.
• @yarnpkg/pnpify has been refactored into 3 packages:
  • @yarnpkg/sdks now contains the Editor SDKs
  • @yarnpkg/pnpify now contains the PnPify CLI compatibility tool that creates in-memory node_modules
  • @yarnpkg/nm now contains the node_modules tree builder and hoister
• @yarnpkg/plugin-node-modules has been renamed to @yarnpkg/plugin-nm
• The --clipanion=definitions commands supported by our CLIs will now expose the definitions on the entry point (rather than on .command)

API

• structUtils.requirableIdent got removed; use structUtils.stringifyIdent instead, which is strictly the same.
• configuration.format got removed; use formatUtils.pretty instead, which is strictly the same, but type-safe.
• httpUtils.Options['json'] got removed; use httpUtils.Options['jsonResponse'] instead, which is strictly the same.
• PackageExtension['description'] got removed, use formatUtils.json(packageExtension, formatUtils.Type.PACKAGE_EXTENSION) instead, which is strictly the same.
• Project.generateBuildStateFile has been removed, the build state is now in Project.storedBuildState.
• Project.tryWorkspaceByDescriptor and Project.getWorkspaceByDescriptor now match on virtual descriptors.

Installs

• Workspaces now get self-references even when under the node-modules linker (just like how it already worked with the pnp linker). This means that a workspace called foo can now safely assume that calls to require('foo/package.json') will always work, removing the need for absolute aliases in the majority of cases.

• The node-modules linker now does its best to support the portal: protocol. This support comes with two important limitations:

  • Projects that make use of such dependencies will have to be run with the --preserve-symlinks Node option if they wish to access their dependencies.
  • Because Yarn installs will never modify files outside of the project due to security reasons, sub-dependencies of packages with portal: must be hoisted outside of the portal. Failing that (for example if the portal package depends on something incompatible with the version hoisted via another package), the linker will produce an error and abandon the install.

• The node-modules linker can now utilize hardlinks. The new setting nmMode: classic | hardlinks-local | hardlinks-global specifies which node_modules strategy should be used:

  • classic - standard node_modules layout, without hardlinks
  • hardlinks-local - standard node_modules layout with hardlinks inside the project only
  • hardlinks-global - standard node_modules layout with hardlinks pointing to global content storage across all the projects using this option

Bugfixes

• Yarn now has a proper governance model.
• The node-modules linker will now ensure that the generated install layouts are terminal, by doing several rounds when needed.
• The node-modules linker will no longer print warnings about postinstall scripts when a workspace depends on another workspace listing install scripts.
• Peer dependencies depending on their own parent are now properly hoisted by the node-modules linker.
• Boolean values will be properly interpreted when specified inside the configuration file via the ${ENV_VAR} syntax.
• Should any of preinstall, install, postinstall fail, the remaining scripts will be skipped.
• The git: protocol will now default to fetching HEAD (rather than the hardcoded master).
• The SIGTERM signal will now be propagated to child processes.
• The PnP linker now schedules packages to be rebuilt if their unplugged folder is removed
• yarn config unset will now correctly unset non-nested properties
• The TypeScript SDK now
• And a bunch of smaller fixes.

Settings

• Various initFields edge cases have been fixed.
• The preferAggregateCacheInfo flag will now also aggregate cleanup reports.
• A new enableMessageNames flag can be set to false to exclude the YNxxxx from the output.

Commands

• yarn init can now be run even from within existing projects (will create missing files).
• yarn init and yarn set version will set the packageManager field.
• yarn set version now downloads binaries from the official Yarn website (rather than GitHub).
• yarn set version from sources will now upgrade the builtin plugins as well unless --skip-plugins is set.
• yarn version apply now supports a new --prerelease flag which replaces how prereleases were previously handled.
• yarn run should be significantly faster to boot on large projects.
• yarn workspaces foreach --verbose will now print when processes start and end, even if they don't have an output.
• yarn workspaces foreach now supports a --from <glob> flag, which when combined with -R will target workspaces reachable from the 'from' glob.
• yarn patch-commit can now be used as many times as you want on the same patch folder.
• yarn patch-commit now supports a new -s,--save flag which will save the patch instead of just printing it.
• yarn up now supports a new -R,--recursive flag which will upgrade the specified package, regardless where it is.
• yarn config unset is a new command that will remove a setting from the local configuration (or home if -H is set).
• yarn exec got support for running shell scripts using Yarn's portable shell.
• yarn plugin import can now install specific versions of the official plugins.
• yarn plugin import will now download plugins compatible with the current CLI by default.
• yarn unlink has been added which removes resolutions previously set by yarn link.

Builtin Shell

• The shell now supports background jobs, with color-coded output.
• It now also supports redirections from file descriptors.

Compatibility

• Running yarn install inside a Yarn v1 project will now automatically enable the node-modules linker. This should solve most of the problems people have had in their migrations. We still recommend to keep the default PnP for new projects, but the choice is yours.
• The patched filesystem now supports file URLs, bigint, and fstat.
• An official ESBuild resolver is now provided under the name @yarnpkg/esbuild-plugin-pnp. We use it to bundle Yarn itself!
• PnP projects can now use the Node exports field - regardless of the Node version.
• The PnP hook now supports the node: protocol (new in Node 16)
• The Prettier SDK does not use PnPify anymore since it was its only remaining use, and was fairly invasive; as a result, the Prettier plugins must be specified in Prettier's plugins configuration property.
• Zip terminal links can now be clicked from within VSCode
• Builtin patches that fail to apply will no longer cause an error (they'll emit a warning and the original sources will be used instead).
  • Remember that patches are a problem for our team too, and that we only do this because we don't have any other option available to us right now - if you wish to help, consider upvoting the relevant pull request in the TypeScript repository or, if you work at Microsoft, perhaps mention to your TypeScript team next door that fixing this would benefit you.

Miscellaneous

• Reporting for HTTP errors has been improved, which should help you investigate registry issues.