Yarn PnP Support Status

[clydin]

With the release of Yarn 2.0, many users may be interested in trying out the new version of the package manager with the Angular CLI. As of 9.0, the Angular CLI does not natively support Yarn 2.0 and its new package management strategy named Plug’n’Play (PnP). However, native support is currently and actively being investigated with several initial steps already in place. Native support is tentatively scheduled for inclusion in 10.0 or beyond with the goal of integrating new major versions of upstream dependencies that provide native support.

For those that are interested in experimenting with building applications using the new package manager, you can use the following instructions to workaround the current issues. WARNING: This is not recommended for use with deployed applications and should not be used in a production environment.

1. Install the workspace dependencies using Yarn 2.0
2. Install the pnpify package: yarn add -D @yarnpkg/pnpify
3. Unplug all Angular related packages including third-party libraries used within the application via yarn unplug <package_name>. This should include at a minimum all @angular scoped packages.
4. If using the E2E command, the webdriver-manager package also needs to be unplugged: yarn unplug webdriver-manager

Once these steps are complete, Angular CLI operations such as serve or build can be used by executing yarn pnpify ng build or yarn pnpify ng serve, respectively.

Please note that manually running the ngcc command with or without the pnpify utility does not currently work.

If any issues are encountered using the workaround steps or for Yarn 2.0 in general, please open a separate issue detailing the problem.

[larixer]

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.

[andreialecu]

Some possibly relevant information regarding improving yarn 2.0 support:

https://github.com/angular/angular-cli/issues/14841#issuecomment-590776160

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.

[Langstra]

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

[klemenoslaj]

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.

[ronnyek]

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.

[andreialecu]

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: https://github.com/angular/angular/issues/38099

[krokofant]

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

[Lonli-Lokli]

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.

[napei]

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?

[JoostK]

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.

[Lonli-Lokli]

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

[Falven]

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.

[andreialecu]

@Falven: support for this is underway and part of it is in https://github.com/orgs/angular/projects/2 which has been mentioned in previous messages in this thread.

[SirBernardPhilip]

I see that the project is now closed. Does this mean that PNP should work with Yarn2? Is it only loose mode though or will all references to node_modules disappear eventually? Edit: And would it be possible for LTS versions to also get support?

[borgez]

expecting in v12?

[RIPT1DE]

I see that the project is now closed. Does this mean that PNP should work with Yarn2? Is it only loose mode though or will all references to node_modules disappear eventually? Edit: And would it be possible for LTS versions to also get support?

It looks like the ng linker is already in v12 stable. According to the docs over here, libraries need to be compiled using angular v12 with the "partialIvy" format, before they would work without unplugging. Im not sure if the built in angular core and common packages are using the partialIvy format or not however..

[petebacondarwin]

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.

[wolftrax5]

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

[bgotink]

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

[wolftrax5]

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

[SirJosh1987]

More trouble than I’ve ever had is getting you f’s to better explain this shit

[crfrolik]

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?

[petebacondarwin]

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.

[SomebodyOdd]

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?

[petebacondarwin]

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.

[SirJosh1987]

Ok I think I've figured it out now

[AwesomeObserver]

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

[daniel-brenot]

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

[hiepxanh]

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

[mikerentmeister]

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

[larixer]

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.

[petebacondarwin]

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.

[michaelfaith]

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

[mikerentmeister]

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?

[clydin]

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

[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...

[larixer]

@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.

[petebacondarwin]

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.

[kylecordes]

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.

[songyang-dev]

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.

[dgerhardt]

Thanks for all the work on the new packaging for Angular 13. With Angular 13.1 and Yarn 3.2 (RC8) I'm now able to successfully build a new ng project with PnP enabled. But unfortunately, this is not yet the case for @angular/material. Once the Material SCSS is imported to the style, the build fails with an sass-loader error because CDK imports cannot be resolved. My first guess would be that the direct use of files from CDK through relative imports from Material causes the issue since the cdk directory is no longer a sibling of the material directory.

SassError: Can't find stylesheet to import.
  ╷
1 │ @use '../../cdk/overlay';
  │ ^^^^^^^^^^^^^^^^^^^^^^^^
  ╵
  .yarn/__virtual__/@angular-material-virtual-f113869c44/0/cache/@angular-material-npm-13.1.1-701561aec7-d592b46c92.zip/node_modules/@angular/material/core/_core.scss 1:1  @forward
  .yarn/__virtual__/@angular-material-virtual-f113869c44/0/cache/@angular-material-npm-13.1.1-701561aec7-d592b46c92.zip/node_modules/@angular/material/_index.scss 18:1     @use
  src/styles.scss 2:1

I have created a reproduction repo: https://github.com/dgerhardt/angular13.1-yarn3.2-pnp-sass-loader-repro

[michaelfaith]

Progress! I'm excited that it's closer to being resolved. @dgerhardt I wonder if it might not be better to open a new issue in the angular/components repo for this, since it seems specific to that library, rather than an issue with the framework/cli anymore? Out of curiosity, have you tested @angular/flex-layout as well?

[dgerhardt]

@michaelfaith The official flex-layout demo project builds successfully with Yarn PnP enabled.

[michaelfaith]

@dgerhardt excellent! Thanks for the info.

[johncrim]

I'm seeing issues building libs and apps on a minimal project (and the same errors in real projects). The 2 issues are listed above.

I also had to fix some missing dependency declarations (angular eslint pulls in @nrwl/devkit, which has a missing dependency), but that worked as expected.

My taste of Yarn PnP was very promising, but it doesn't seem like the angular ecosystem is ready to benefit from it yet.

[michaelfaith]

@johncrim thanks for the investigation and for opening the issues to resolve. It's something I'm eager to take advantage of.

[johncrim]

I wasn't aware that Yarn 3.1 doesn't really/fully implement ESM imports - which explains the issues I reported. The issues I reported go away if you yarn set version canary && yarn install - so ESM is indeed working in Yarn 3.2 prerelease.

There's a new error after that.

[merceyz]

I wasn't aware that Yarn 3.1 doesn't really/fully implement ESM imports

NIT: It does but it isn't enabled unless the entrypoint is also ESM, the 3.2 version will enable it regardless of what the entrypoint is (ref https://github.com/yarnpkg/berry/pull/3667)

[timeimp]

Using the latest yarn 3.2.0-rc.11 and @angular/cli-13.2.0-next versions, this error message appears when running yarn ng build:

An unhandled exception occurred: The requested module '@angular/compiler' does not provide an export named 'SafeCall'
See "/private/var/folders/h4/98bjh9014mgbr7b0nyjbyf280000gn/T/ng-XTZX0G/angular-errors.log" for further details.

with the full logfile showing

[error] file:///admin-client/.yarn/__virtual__/@angular-compiler-cli-virtual-a56bca125e/0/cache/@angular-compiler-cli-npm-13.2.0-rc.0-7a45d0d9ee-c4ded9d4e2.zip/node_modules/@angular/compiler-cli/bundles/chunk-PRLCFFMX.js:2956
import { BindingPipe, Call as Call2, DYNAMIC_TYPE, ImplicitReceiver as ImplicitReceiver4, PropertyRead as PropertyRead4, PropertyWrite as PropertyWrite3, SafeCall, SafePropertyRead as SafePropertyRead3, ThisReceiver, TmplAstBoundAttribute, TmplAstBoundText, TmplAstElement as TmplAstElement3, TmplAstIcu, TmplAstReference as TmplAstReference3, TmplAstTemplate as TmplAstTemplate2, TmplAstTextAttribute as TmplAstTextAttribute2, TmplAstVariable as TmplAstVariable2 } from "@angular/compiler";
                                                                                                                                                          ^^^^^^^^
SyntaxError: The requested module '@angular/compiler' does not provide an export named 'SafeCall'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async ModuleJob.run (node:internal/modules/esm/module_job:181:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async importModuleDynamicallyWrapper (node:internal/vm/module:437:15)
    at async readTsconfig (/admin-client/.yarn/__virtual__/@angular-devkit-build-angular-virtual-c4cc700b00/0/cache/@angular-devkit-build-angular-npm-13.1.4-2572f0583a-321d7737c4.zip/node_modules/@angular-devkit/build-angular/src/utils/read-tsconfig.js:44:54)
    at async configureI18nBuild (/admin-client/.yarn/__virtual__/@angular-devkit-build-angular-virtual-c4cc700b00/0/cache/@angular-devkit-build-angular-npm-13.1.4-2572f0583a-321d7737c4.zip/node_modules/@angular-devkit/build-angular/src/utils/i18n-options.js:124:22)
    at async generateI18nBrowserWebpackConfigFromContext (/admin-client/.yarn/__virtual__/@angular-devkit-build-angular-virtual-c4cc700b00/0/cache/@angular-devkit-build-angular-npm-13.1.4-2572f0583a-321d7737c4.zip/node_modules/@angular-devkit/build-angular/src/utils/webpack-browser-config.js:68:36)
    at async initialize (/admin-client/.yarn/__virtual__/@angular-devkit-build-angular-virtual-c4cc700b00/0/cache/@angular-devkit-build-angular-npm-13.1.4-2572f0583a-321d7737c4.zip/node_modules/@angular-devkit/build-angular/src/builders/browser/index.js:67:70)

Which seems very promising! 👏

Is there a place to read more about what is blocking or remaining for the CLI to support PnP?

Cheers!

[JoostK]

Using the latest yarn 3.2.0-rc.11 and @angular/cli-13.2.0-next versions, this error message appears when running yarn ng build:

An unhandled exception occurred: The requested module '@angular/compiler' does not provide an export named 'SafeCall'
See "/private/var/folders/h4/98bjh9014mgbr7b0nyjbyf280000gn/T/ng-XTZX0G/angular-errors.log" for further details.

@timeimp Are your @angular/compiler and @angular/compiler-cli versions in sync? From that error message it looks like the @angular/compiler package you're using is too old.

[merceyz]

For what it's worth; we've added an e2e test in the Yarn repo verifying that the Angular CLI and PnP work https://github.com/yarnpkg/berry/pull/3949

[timeimp]

For what it's worth; we've added an e2e test in the Yarn repo verifying that the Angular CLI and PnP work https://github.com/yarnpkg/berry/pull/3949

I will go ahead tomorrow and test this out. It is possible my caches may be stale but these commands were run from the existing registry packages and not custom and builds.

Thanks so much 👍

[michaelfaith]

For what it's worth; we've added an e2e test in the Yarn repo verifying that the Angular CLI and PnP work yarnpkg/berry#3949

This is exciting news

[timeimp]

For what it's worth; we've added an e2e test in the Yarn repo verifying that the Angular CLI and PnP work yarnpkg/berry#3949

So I managed to get the compiled browser application bundle generated (thanks @JoostK!), but now @angular/material or sass-loader is giving an error:

yarn ng build --configuration=production
✔ Browser application bundle generation complete.

🥳🎉🥳🎉🥳🎉

(a few moments later...)

 Error: Module build failed (from ./.yarn/__virtual__/sass-loader-virtual-8adf857255/0/cache/sass-loader-npm-12.4.0-3d3847fd35-0f7ca3633e.zip/node_modules/sass-loader/dist/cjs.js):
SassError: Can't find stylesheet to import.
  ╷
5 │ @forward '../cdk/a11y/index.import';
  │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ╵
  .yarn/__virtual__/@angular-material-virtual-bc8b551dc8/0/cache/@angular-material-npm-13.2.0-rc.0-fe79c5e13a-a9dda2e4ac.zip/node_modules/@angular/material/_theming.scss 5:1  @import
  src/theme/theme-variables.scss 11:9                                                                                                                                          @import
  src/main.scss 7:9                                                                                                                                                            root stylesheet

I've read around that the Yarn way of using these __virtual__ paths can cause issues during path reconciliation. I'm going to see if there's anything I can do to fix this but either way... progress! 👏

[PowerKiKi]

@timeimp you might want to have a look at https://github.com/angular/components/issues/24128, which was reported earlier in this thread by @dgerhardt

[ericparton]

Does anyone know if the angular.json file supports PnP in any way? In my angular.json, I have a bunch of hard coded references to third party assets and styles that used to be located in the node_modules directory, which cause the build to fail when node_modules doesn't exist anymore.

Just for example:

"assets": [ "src/assets", "src/config.js", "src/scripts/head.js", { "glob": "/*", "input": "node_modules/internal-assets/public/img", "output": "/img" }, { "glob": "/*", "input": "node_modules/internal-assets/public/fonts", "output": "/fonts" } ], "styles": [ "src/styles/sass/styles.scss", "node_modules/font-awesome/css/font-awesome.css", "node_modules/ngx-bootstrap/datepicker/bs-datepicker.css", "src/styles/dashboard.css", "src/styles/sidebar.css" ], "scripts": [ "node_modules/jquery/dist/jquery.min.js", "node_modules/bootstrap/dist/js/bootstrap.min.js", "node_modules/popper.js/dist/umd/popper.min.js", "node_modules/jquery.qrcode/jquery.qrcode.min.js", "node_modules/jquery-caret-plugin/dist/jquery.caret.min.js", "src/scripts/sidebar.js", "node_modules/internal-assets/public/js/static-utils.js" ]

I'm kind of at a loss on how to proceed with switching over to PnP at this point.

[michaelfaith]

Curious about that as well.

[ericparton]

Just to see if I could get it to work somehow, I manually put all of those missing files in my angular.json at the location that they needed to be in. Running ng build after that failed with what looks like hundreds of these errors:

./src/app/downloads/downloads-index/downloads-index.component.ts:2:0-151 - Error: Module not found: Error: Can't resolve '/Users/ericp/Projects/public/public_frontend/node_modules/@babel/runtime/helpers/esm/createClass.js' in '/Users/ericp/Projects/public/public_frontend/src/app/downloads/downloads-index'

It seems like the Yarn PnP support is still pretty far from being ready, unfortunately. Someone might want to reach out to the Yarn people, since their documentation says that Angular 13 does support PnP:

https://yarnpkg.com/features/pnp

[saxicek]

The examples you provided are not Angular itself, but your project dependencies (like Font Awesome). It is your responsibility to make them right. Try using ~package/… for paths - that way SCSS can be impoted and it may work for other imports(no guarantee).

pá 25. 2. 2022 v 19:28 odesílatel Eric Parton @.***> napsal:

Just to see if I could get it to work somehow, I manually put all of those missing files in my angular.json at the location that they needed to be in. Running ng build after that failed with what looks like hundreds of these errors:

./src/app/downloads/downloads-index/downloads-index.component.ts:2:0-151 - Error: Module not found: Error: Can't resolve @.***/runtime/helpers/esm/createClass.js' in '/Users/ericp/Projects/public/public_frontend/src/app/downloads/downloads-index'

It seems like the Yarn PnP support is still pretty far from being ready, unfortunately. Someone might want to reach out to the Yarn people, since their documentation says that Angular 13 does support PnP:

https://yarnpkg.com/features/pnp

— Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/16980#issuecomment-1051092431, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANBDGUV4JLEPG2Q6CKXYGTU47C3RANCNFSM4KVPSODQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ericparton]

It is possible to manually move the node_modules assets referenced by the angular.json to another directory as a part of some custom pre-build step, but that doesn't really seem like an ideal situation.

[Mithras]

I think just removing "node_modules" for stuff referenced in angular.json work fine, e.g.

"styles": [
    "bootstrap/dist/css/bootstrap.css"
],

I haven't tested that it actually works as switching to PnP breaks other stuff in our repo but at least it gets rid of ng serve "no such file or directory" error.

[Pablodotnet]

I think just removing "node_modules" for stuff referenced in angular.json work fine, e.g.

"styles": [
    "bootstrap/dist/css/bootstrap.css"
],

I haven't tested that it actually works as switching to PnP breaks other stuff in our repo but at least it gets rid of ng serve "no such file or directory" error.

It doesnt worked :( tried It angular.json and in a lib's ng-angular.json, didnt worked

[Lonli-Lokli]

So what is the status of this story - is it completed, work-in-progress or just forgotten?

[daniel-brenot]

So what is the status of this story - is it completed, work-in-progress or just forgotten?

I'm also wondering this. Generallly from my understanding this should be working, but angular material perticularly seems to have issues.

[Pablodotjs]

ng update does not work if we are using yarn plug and play

[Pablodotjs]

Someone have tried using any angular schematic while using yarn plug and play? Seems something failling here too with esbuild searching esbuild-android64 or something like that

[Pablodotjs]

Today tried to build an angular universal application and I'm struggling with it, this issue should be high priority for angular team, angular does not go well with yarn plug and play, to reproduce the issue just set plug and play to an angular and start struggling :/

[ld210]

So.... i was able to switch our project to Plug&Play, but with a catch. I tried with a fresh app and the same thing happened : I create a new app with ng new testApp --skip-install, and did a pnp install. After that, a yarn ng serve generated a bundle, but i end up with this error :

✔ Browser application bundle generation complete.

Initial Chunk Files | Names   | Raw Size
runtime.js          | runtime |  6.51 kB | 

4 unchanged chunks
Build at: 2022-07-01T06:00:57.554Z - Hash: 0d049c2870440207 - Time: 20ms

./src/main.ts - Error: Module build failed (from ./.yarn/__virtual__/@ngtools-webpack-virtual-97fed464f9/0/cache/@ngtools-webpack-npm-14.0.4-528d27ccc3-c14b7ac0ba.zip/node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Emit

./src/polyfills.ts - Error: Module build failed (from ./.yarn/__virtual__/@ngtools-webpack-virtual-97fed464f9/0/cache/@ngtools-webpack-npm-14.0.4-528d27ccc3-c14b7ac0ba.zip/node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Emit

Error: Failed to initialize Angular compilation - Cannot locate the 'node_modules' directory.

✖ Failed to compile.

After that, i added an empty node_modules folder to the project, rerun a yarn ng serve, and everything is working fine, node_modules folder is still empty, but i guess the CLI needed it to be happy. yarn ng build and yarn ng test are working too. I did the same with our real app and all its dependencies, and it's working fine, full pnp. It would be nice if we could get rid off node_modules completely, though.

Here is the ng version :

Angular CLI: 14.0.4
Node: 16.13.1
Package Manager: yarn 3.2.1 
OS: darwin arm64

Angular: 14.0.4
... animations, cdk, cli, common, compiler, compiler-cli, core
... elements, forms, language-service, material
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1400.4 (cli-only)
@angular-devkit/build-angular   14.0.4
@angular-devkit/core            14.0.4 (cli-only)
@angular-devkit/schematics      14.0.4 (cli-only)
@schematics/angular             14.0.4 (cli-only)
rxjs                            7.5.5
typescript                      4.7.4

[Lonli-Lokli]

@ld210 what is your yarn version (1,2,3)? I wasn't able to even migrate with yarn v3, although corresponding Ng issue is closed

[ld210]

@Lonli-Lokli Yarn version is 3.2.1 But i may have spoke too soon. yarn ng lint is not happy at all, but only with *.spec.ts files... EDIT : So,i have problems with the linter on the project i'm currently migrating to pnp. I tried with a new project, installed @angular-eslint/schematics, add the unlisted dependencies in .yarnrc.yml, and it is working as expected. Weird...

[michaelfaith]

Error: Failed to initialize Angular compilation - Cannot locate the 'node_modules' directory.

✖ Failed to compile.

Searching for that error in the repo, it appears to be connected to the ngcc processor: https://github.com/angular/angular-cli/blob/7ababc210b3eb023bfd4c8f05178cb2f75472bb2/packages/ngtools/webpack/src/ngcc_processor.ts#L235 If you follow how that's being used, you see that if the node_modules folder is read only then it just skips the processing entirely, but if node_modules isn't there at all, it just errors out. It seems like it should just skip if it isn't there, like it does in cases where it's read only. So it may be a relatively easy fix

[Lonli-Lokli]

That's the case for yarn only, npm should still report an error

[michaelfaith]

That's the case for yarn only, npm should still report an error

Why should it report an error in this logic? This logic is only responsible for running the ngcc processor. It's skipping that process if node_modules is read only, it would make sense to skip also if it isn't there. It has the same impact on the ability to run ngcc. Let npm report errors for its own needs.

[JoostK]

Error: Failed to initialize Angular compilation - Cannot locate the 'node_modules' directory.

✖ Failed to compile.

Searching for that error in the repo, it appears to be connected to the ngcc processor:

https://github.com/angular/angular-cli/blob/7ababc210b3eb023bfd4c8f05178cb2f75472bb2/packages/ngtools/webpack/src/ngcc_processor.ts#L235

If you follow how that's being used, you see that if the node_modules folder is read only then it just skips the processing entirely, but if node_modules isn't there at all, it just errors out. It seems like it should just skip if it isn't there, like it does in cases where it's read only. So it may be a relatively easy fix

Thanks for this info, we're updating that logic to work without node_modules in #23487 (and ng-packagr as well in a follow up PR)

[Lonli-Lokli]

@JoostK I've updated to the latest 14.0.5 (with the fix), switched to PnP and tried to run yarn start, but faced an issue

[error] Error: ENOENT: no such file or directory, lstat D:\gitlab\cv-app\frontend\cv-ui\node_modules'
    at Object.realpathSync (fs.js:1800:7)
    at NodeFS.realpathSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:22251:45)
    at makeCallSync.archivePath.archivePath (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:24291:26)
    at ZipOpenFS.makeCallSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:24725:14)
    at ZipOpenFS.realpathSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:24290:17)
    at VirtualFS.realpathSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:24041:26)
    at PosixFS.realpathSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:23818:41)
    at URLFS.realpathSync (D:\gitlab\cv-app\frontend\cv-ui\.pnp.cjs:23818:41)
    at resolveGlobalStyles (D:\gitlab\cv-app\frontend\cv-ui\.yarn\__virtual__\@angular-devkit-build-angular-virtual-19782774cb\0\cache\@angular-devkit-build-angular-npm-14.0.5-28514d9bac-2ba0dc5381.zip\node_modules\@angular-devkit\build-angular\src\webpack\configs\styles.js:60:31)
    at getStylesConfig (D:\gitlab\cv-app\frontend\cv-ui\.yarn\__virtual__\@angular-devkit-build-angular-virtual-19782774cb\0\cache\@angular-devkit-build-angular-npm-14.0.5-28514d9bac-2ba0dc5381.zip\node_modules\@angular-devkit\build-angular\src\webpack\configs\styles.js:93:70)

Angular CLI: 14.0.5
Node: 14.18.2
Package Manager: yarn 3.2.1
OS: win32 x64

Angular: 14.0.4
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router, service-worker

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1400.5 (cli-only)
@angular-devkit/build-angular   14.0.5
@angular-devkit/core            14.0.5 (cli-only)
@angular-devkit/schematics      14.0.5 (cli-only)
@angular/cli                    14.0.5
@schematics/angular             14.0.5 (cli-only)
rxjs                            7.5.5
typescript                      4.7.3

[ld210]

@JoostK We just updated to v14.0.5. I was able to delete completely node_modules folder and everything is working fine. Thank you !

[Lonli-Lokli]

It appears my problem is related to styles in angular.json, declared this way

"styles": [
              "./node_modules/normalize.css/normalize.css",

What is the correct way for declaring them?

[ld210]

@Lonli-Lokli I have a similar issue with "$schema": "./node_modules/@angular/cli/lib/config/schema.json" It doesn't throw an error preventing the build, though, but it may be a real issue in the futur.

[clydin]

@Lonli-Lokli The styles option supports package resolution. Since the normalize.css package contains a main field pointing to the stylesheet, you can replace "./node_modules/normalize.css/normalize.css" with just "normalize.css". This package resolution does not yet support custom conditions for the package exports field. So for other packages that use the exports field this may not work yet.

@ld210 The $schema field is only used to inform the IDE of the schema so that the IDE can provide tooltips and error detection. Unfortunately, most IDE's do not support package resolution for this field and a relative path is needed for IDEs to find it within the project. However, we are investigating integration of the schema into the Angular language service which may provide an alternative to the relative schema path.

[ld210]

Awesome, thanks @clydin

[michaelfaith]

This package resolution does not yet support custom conditions for the package exports field. So for other packages that use the exports field this may not work yet.

So then that means larger libraries with styles, like Angular Material wouldn't work. They package their prebuilt themes as .css files (which I believe are exported via package exports). So is there not support for that yet?

[michaelfaith]

Confirmed. I just tested using this in the angular.json styles array:

"styles": [
    "@angular/material/prebuilt-themes/indigo-pink.css",
    "src/styles.scss"
  ],

Their package.json has this export:

"./prebuilt-themes/indigo-pink.css": {
    "style": "./prebuilt-themes/indigo-pink.css"
  },

And when trying to run ng serve I get:

An unhandled exception occurred: ENOENT: no such file or directory, lstat 'C:\Users\<user>\Desktop\test147\@angular'

[clydin]

@michaelfaith If referenced directly in the styles option, then they would not be supported currently. But if imported in the styles.css (or styles.scss, etc.) file generated by a new project, then they will work. It is only the direct option use that has the limitation.

[michaelfaith]

Thanks. I can work with that. Do you think exported styles will be able to be used in the angular.json like that at some point in the future?

[snebjorn]

I've run into an issue adding @angular-eslint. Please advice :)

❯ yarn ng add @angular-eslint/schematics
ℹ Using package manager: yarn
✔ Found compatible package version: @angular-eslint/[email protected].
✔ Package information loaded.

The package @angular-eslint/[email protected] will be installed and executed.
Would you like to proceed? Yes
✔ Packages successfully installed.
@angular-eslint/schematics tried to access @angular-devkit/schematics, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: @angular-devkit/schematics (via "@angular-devkit\schematics")
Required by: @angular-eslint/schematics@virtual:78dc4916cfdcd5b55aa68d7e49b61f6c729480766ff9c1d037a6a9b6c10c97a99181ab991297738a8127f52a35b10ad0c33147cf0c0f737065ac4b7bb3dfbc64#npm:14.0.2 (via ~\ng14-pnpm\.yarn\__virtual__\@angular-eslint-schematics-virtual-f25c01b02a\0\cache\@angular-eslint-schematics-npm-14.0.2-b57b98b3ce-7b1418297e.zip\node_modules\@angular-eslint\schematics\dist\ng-add\)

- ~\ng14-pnpm\.yarn\__virtual__\@angular-eslint-schematics-virtual-f25c01b02a\0\cache\@angular-eslint-schematics-npm-14.0.2-b57b98b3ce-7b1418297e.zip\node_modules\@angular-eslint\schematics\dist\ng-add\index.js                                                                                                                                                                                                 dist\ng-add\index.js
- ~\ng14-pnpm\.yarn\cache\@angular-devkit-schematics-npm-14.0.5-5289456c8a-d0a731bb27.zip\node_modules\@angular-devkit\schematics\tools\export-ref.js
- ~\ng14-pnpm\.yarn\cache\@angular-devkit-schematics-npm-14.0.5-5289456c8a-d0a731bb27.zip\node_modules\@angular-devkit\schematics\tools\index.js
- ~\ng14-pnpm\.yarn\cache\@angular-cli-npm-14.0.5-eccde1fd20-5bc4ae64b3.zip\node_modules\@angular\cli\src\commands\add\cli.js
- ~\ng14-pnpm\.yarn\cache\@angular-cli-npm-14.0.5-eccde1fd20-5bc4ae64b3.zip\node_modules\@angular\cli\src\command-builder\command-runner.js
- ~\ng14-pnpm\.yarn\cache\@angular-cli-npm-14.0.5-eccde1fd20-5bc4ae64b3.zip\node_modules\@angular\cli\lib\cli\index.js
- ~\ng14-pnpm\.yarn\cache\@angular-cli-npm-14.0.5-eccde1fd20-5bc4ae64b3.zip\node_modules\@angular\cli\lib\init.js

❯ yarn ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 14.0.5
Node: 16.13.0
Package Manager: yarn 3.2.1
OS: win32 x64

Angular: 14.0.5
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1400.5 (cli-only)
@angular-devkit/build-angular   14.0.5
@angular-devkit/core            14.0.5 (cli-only)
@angular-devkit/schematics      14.0.5 (cli-only)
@schematics/angular             14.0.5 (cli-only)
rxjs                            7.5.6
typescript                      4.7.4

[Lonli-Lokli]

@snebjorn you should follow instructions from yarn https://yarnpkg.com/getting-started/migration#fix-dependencies-with-packageextensions

[snebjorn]

@Lonli-Lokli thanks. I was unaware of these instructions.

If anyone else runs into this, this made it work.

#.yarnrc.yml
packageExtensions:
  "@angular-eslint/schematics@*":
    dependencies:
      "@angular-devkit/schematics": "*"
      "@angular-devkit/core": "*"

I guess all that is left is to report this dependency issue to @angular-eslint

Reported: https://github.com/angular-eslint/angular-eslint/issues/1091

[michaelfaith]

I've posted this issue to enable module resolution from package exports for entries in the angular.json styles array, as discussed above. This will be necessary for fully supporting yarn pnp. It's currently up for community voting. If you're following this thread, I assume it's something you're interested in and might consider upvoting: https://github.com/angular/angular-cli/issues/23568

[Lonli-Lokli]

Here is the sample of application with failing scss loading via styles.scss. Is it on CLI side, ot it's webpack's sass-loader issue?

Just clone and start https://github.com/Lonli-Lokli/yarn_pnp_scss/blob/master/src/styles.scss

[Miccighel]

How are we supposed to run the command to update Angular's package while using Yarn PnP?

Back then I used to run, say, ng update @angular/cli. How we may do that now?

[snebjorn]

How are we supposed to run the command to update Angular's package while using Yarn PnP?

Back then I used to run, say, ng update @angular/cli. How we may do that now?

I assume yarn ng update @angular/cli

I had to run ng serve and ng lint through yarn (yarn ng serve and yarn ng lint) for it to work. So I'm guessing it's the same for update. I believe that's what this section is about :) https://yarnpkg.com/getting-started/migration#final-notes

[Miccighel]

Actually with Angular's core packages I get a "@angular/cli is not a dependency".

[Pablodotjs]

try with yarn pnpify, install it yarn add @yarnpkg/pnpify and run yarn pnpify ng update, but it will not work properly due to an issue of ngcc if I dont remember wrong, but you can give it a try

[Lonli-Lokli]

Here is the sample of application with failing scss loading via styles.scss. Is it on CLI side, ot it's webpack's sass-loader issue?

Just clone and start https://github.com/Lonli-Lokli/yarn_pnp_scss/blob/master/src/styles.scss

Does anyone know the answer - is it an issue with CLI or webpack?

[michaelfaith]

Looking at your repo, i don't see tippy.js in your package dependencies. And looking at tippy's package.json i don't see that they're exporting any of their css files. So I'm not sure how webpack would know how to load them. They seem to be relying on the location in the file structure. So it may not be the cli or webpack's fault, but tippy's.

[michaelfaith]

I stand corrected. I did a quick test with Create React App, just to see if tippy had issues with yarn pnp and React. I did the following:

• Created new CRA app - yarn create react-app test-tippy
• Ejected CRA to avoid any CRA pnp issues distracting from the test - yarn eject
• Installed tippy - yarn add tippy.js
• Upgraded yarn to berry - yarn set version stable
• Installed - yarn
• Changed to pnp - Removed nodeLinker: node-modules from .yarnrc.yml
• Installed again to remove node_modules - yarn
• Added tippy to App.js as follows:

import tippy from 'tippy.js';
import 'tippy.js/dist/tippy.css';
import 'tippy.js/themes/light.css';
import './App.css';

tippy('#myButton', {
  content: 'My tooltip!',
  theme: 'light',
});
function App() {
  return (
    <div className="App">
      <header className="App-header">
        <p>
          <button id="myButton">My button</button>
        </p>
      </header>
    </div>
  );
}

export default App;

This ran successfully. Styles loaded and were visible in the ui. So the lack of package exports in tippy's package.json don't seem to be an issue with webpack loading it. I didn't test anything with sass, since my main objective was just to see if it was able to load at all, and it did.

[Lonli-Lokli]

@michaelfaith tippy is a dependency of @ngneat/helipopper So basically yes, the question is why it's not working when using physical relative path to styles. Without PnP it works with ~ syntax.

[michaelfaith]

@Lonli-Lokli After downloading your repo, installing tippy.js (yarn add tippy.js) as an explicit dependency and updating your styles.scss to use @import instead of meta.load-css it's working.

@import 'tippy.js/dist/tippy.css';
@import 'tippy.js/themes/light.css';
@import 'tippy.js/animations/scale.css';

Yarn 2+ is far less forgiving about implicit dependencies. Unlike yarn 1, you have to explicitly declare any dependencies you're referencing/loading directly within your project. I tried switching to @import before installing, just to see if that might be the issue, but that didn't work either, until i did the install. And similarly, i tried switching back to meta.load-css after install and that still didn't work.

[Lonli-Lokli]

@michaelfaith You are right, without yarn add tippy.js error appears. So with @import error do not occur, while @include failing. Seems like the problem is on loader side.

Just fyi, The Sass team discourages the continued use of the @import rule https://sass-lang.com/documentation/at-rules/import

[michaelfaith]

Agreed, should probably be addressed by the loader. And looks like @use fails too

@use 'tippy.js/dist/tippy.css' as *;
@use 'tippy.js/themes/light.css' as *;
@use 'tippy.js/animations/scale.css' as *;

[Lonli-Lokli]

One more strange think I notices is that if I create smth failing in the styles.scss and try to fix it in new ng build, it will still report an old error - assuming smth wrong is with .cache folder in pnp mode.