Another way of making Angular 9 work with Yarn 2.0 is to use nodeLinker: node-modules in <project_root>/.yarnrc.yml, this will use node_modules scheme for installation.

Yarn team is investing into node_modules support and trying to make it work better than it was in Yarn 1.x, but the future is definitely not with node_modules. node_modules scheme has fundamental technical limitations that makes it not as scalable as Plug'n'Play scheme both in terms of projects size (things become extremely slow on projects with lots of dependencies) and in terms of features we can attach to the scheme (it is hard to keep up with good installation performance even for minimal set of features).

Some possibly relevant information regarding improving yarn 2.0 support:

#14841 (comment)

Replacing read-package-tree with a createRequire implementation might be a first step in that direction. The comment above links to a PR in gatsby where they did something similar.

I noticed that @clydin authored most of the code in that file, perhaps #14841 could be fixed in the process as well.

How does 2.1 with node_modules linker improvements impact this issue?

https://dev.to/arcanis/yarn-2-1-git-workspaces-focused-installs-loose-mode-live-playground-4kfc

https://yarnpkg.com/configuration/yarnrc#nodeLinker

With nodeLinker configured to node_modules I was able to migrate a small Angular CLI project without a single issue, with zero installs configuration even.

I'm not suggesting it would be trivial to fix this and have it automatically work the way yarn 2 works by default out of box, in addition to continuing to support NPM... but I would say this would probably go a long ways to improve developer experience.

Can't wait until node_modules (at least the way it works today) is a thing of the past.

There is ongoing work right now in @angular core packages to rework things in a way that would allow Yarn2+PnP to work natively.

You can read more and track the progress here: angular/angular#38099

Since the above linked issue was closed we can track the progress here https://github.com/orgs/angular/projects/2

Is there any specific story for that? A lot of issues getting closed with sentence 'track progress here' but no one issue in this project has specific description from closing ones.

Since the above linked issue was closed we can track the progress here https://github.com/orgs/angular/projects/2

@JoostK I'm interested in when this linker will be available and if it'll solve yarn 2.0 pnp support? The project board appears to be mostly complete, and with 11.1 just coming out I'm wondering if there's a way we can test this before it's released?

Since the above linked issue was closed we can track the progress here https://github.com/orgs/angular/projects/2

@JoostK I'm interested in when this linker will be available and if it'll solve yarn 2.0 pnp support? The project board appears to be mostly complete, and with 11.1 just coming out I'm wondering if there's a way we can test this before it's released?

The linker functionality is indeed functionally working, but we're not yet ready to accept published libraries in this new way (we have yet to review the API that would eventually be published to NPM, which needs special considering as it needs to be backwards/forwards compatible). Regarding pnp support, I suspect that it requires that all dependencies no longer depend on ngcc to work correctly, as otherwise you'd still need ngcc which mutates node_modules. So getting this to a working state is in the hands of library maintainers, once the linker is considered stable.

It may be possible to test this support by manually compiling all dependent libraries using the new way and then seeing if that works, but I suppose that it wouldn't tell the whole story as it wouldn't download packages from NPM, which could arguably affect how pnp works.

Sorry but is my understanding correct, that to make pnp works it's required for all angular libs to get updated by their maintainers?

So does this mean Angular is dead in the water as it will always require management of gigs of dependencies, long CI build times, ngcc compilation, unextendible principles coupled with the insurmountable goal of updating every existing Angular library to support pnp functionality? Or is there a streamlined plan to modernize? It seems like nobody wants to take responsibility for these topics on pnp and everybody is just delegating.

Im not sure if the built in angular core and common packages are using the partialIvy format or not however..

The plan is for the Angular packages (framework, CDK, Material, etc) to be published using partial-ivy format from Angular 13.0.0 onwards, to coincide with View Engine removal - assuming that all goes well with this approach during the 12.x active period.

From that point on application developer will begin to be able to benefit setups that require you not to mutate node_modules, such as yarn2, pnpm, lerna, etc, as long as all the Angular libraries in their dependency tree are partial-ivy format. As long as any are still in View Engine format, then you still require ngcc, which will mutate node_modules.

So how to suppose to build a lib? ng build my-lib Cannot find the module to builder, because is on .yarn/cache ,

@wolftrax5 The globally installed @angular/cli doesn't look inside .yarn/cache, you can use yarn ng build my-lib instead.

thanks for the answer @bgotink, I tried, everything run well until the building part.

$ yarn set version berry
$ yarn dlx --package @angular/cli ng new my-workspace --directory=. --packageManager=yarn --create-application=false
$ yarn add ng-packagr@npm:12.0.0
$ yarn ng generate library mpm-lib

$ yarn ng build my-lib
Building Angular Package

------------------------------------------------------------------------------
Building entry point 'my-lib'
------------------------------------------------------------------------------
✖ Compiling TypeScript sources through NGC
ERROR: Cannot locate the 'node_modules' directory.

Need to modify or add something on tsconfig.json? like here but with the ".yarn/cache /"

As long as any are still in View Engine format, then you still require ngcc, which will mutate node_modules.

In that case, would it be possible to get a new a new version of ngcc that doesn't mutate node_modules?

As long as any are still in View Engine format, then you still require ngcc, which will mutate node_modules.

In that case, would it be possible to get a new a new version of ngcc that doesn't mutate node_modules?

Indeed we have introduced the new partially compiled Ivy format for Angular libraries.

Indeed we have introduced the new partially compiled Ivy format for Angular libraries.

But how does exactly this help in getting support for Yarn 2.0?
Older third-party packages that do require nggc won't magically go away anytime soon, possibly even never, because there are lots of them out there that just work, even with the latest Angular versions and changes.

If I understand the situation correctly, making all of this work is a matter of storing ngcc's output somewhere other than node_modules, because it's the only thing (in Angular's own tools anyway) that mutate node_modules.
Maybe I'm missing some option that changes the path to ngcc's output? If there is no such feature, are there any plans to make this happen? If not, does that mean that using older packages locks you out of Yarn PnP feature because there is no way to not modify the node_modules directory?

The problem ngcc has is that build tools rely upon stuff in node_modules, such as TypeScript typings files (.d.ts files). These tools are not easy to configure to read this information from outside node_modules, and in particular very hard to do this in a way that would work in general.

Since we have a solution (partial compilation and linking) which indeed is designed to avoid the need to mutate node_modules, this is what we would like to move towards going forward.

It is true that packages that do not update to publish in ivy format will lock downstream applications into using ngcc. So I would recommend that the best course of action is to lobby those library projects to migrate to the new format that will enable your application projects to drop ngcc. Angular itself will migrate its own published format to this in 13.0.0, since we will no longer have to support View Engine projects from that version onwards.

Hi! Yarn 3.0 is released, any update for this and 2.0?

So am i given to expect that this should then be somewhat working with the introduction of angular 13.0 later this year?

I switched pnpm 1 year ago since I give up on yarn. I belive it faster than any other and you should give a chance to it

Now that Angular 13 is released, with updates to angular-linker, are there any updates to this?

The title of this issue is misleading, it should rather be Yarn PnP Support Status or Yarn 2+ PnP Support Status, because Yarn 2+ with node_modules (nodeLinker: node-modules in .yarnrc.yml) has been always supported by Angular.

Now that the main Angular packages are published in partial-ivy format, the path to using Yarn PnP is unblocked.
Be aware that as long as your project uses "any" library that is still published in ViewEngine mode, then you will still see ngcc running over your node_modules. In which case you will not be able to use PnP.

I'm excited to have this as an option now!

Now that the main Angular packages are published in partial-ivy format, the path to using Yarn PnP is unblocked.

Any idea why I am still seeing ngcc running when running ng build in an Angular 13 app when ALL dependencies are either set to partial or full ivy compilation?

@mikerentmeister If you are encountering an issue with ngcc, please open a separate issue with a reproduction if possible.

So ngcc will run whatever your project setup, since it needs to check for ViewEngine packages. But if there are none there it should effectively be a noop. That being said, I think it may still create a manifest file of all the packages that it checked...

@petebacondarwin

So ngcc will run whatever your project setup, since it needs to check for ViewEngine packages. But if there are none there it should effectively be a noop. That being said, I think it may still create a manifest file of all the packages that it checked...

It might result in an incompatibility with pnp, because pnp mounts zip archives in read-only mode to the require.resolve paths on the virtual file system. If some tool writes straight to <project_root>/node_modules/.dot_something/... it is okay since this path is non-virtual, but writing to the require.resolve paths results in an EROFS error because they are mapped to read-only zip archives.

I believe there is only one problematic place in ngcc regarding "noop" writing to node_modules: writing a "lockfile" during parallel processing:

export function getLockFilePath(fs: PathManipulation) {
  return fs.resolve(require.resolve('@angular/compiler-cli/ngcc'), '../__ngcc_lock_file__');
}

You can see that this is writing to the @angular/compiler-cli/ngcc directory. We should change this to be a top level .ngcc directory directly below the node_modules (or other basePath) directory.

Based on seeing similar issues with other tools in the Node ecosystem, it is broadly safer to write into a node_module/.foo directory, versus inside of a node_modules/FOO/ directory.

I'm looking forward to seeing an improvement to the size of Angular projects! Currently, node modules take up 300+ MB starting from an empty project.