Feat: Using yarn instead of npm

[phillipplum]

Hello, it would be great if you could decide whether to use npm or yarn. Or it may be recognized automatically. For example in package.json. Instead of npm i -> yarn.

[johannesschobel]

This should be covered by nrwl/nx automatically.

In your angular.json file in the root of your project, add the following line:

{
  "version": 1,
  "newProjectRoot": "",
  "projects": {
    // ...
  },
  "cli": {
    // ...
    "defaultCollection": "@nrwl/workspace",
+   "packageManager": "yarn"
  },
  "schematics": {
    // ...
  }
}

that should do the trick..

[phillipplum]

Yes, thats right.

But when you look in this line: https://github.com/nstudio/xplat/blob/223013cc27ea57f319223660fa36fa97d509431e/packages/ionic-angular/src/schematics/application/index.ts#L78 xplat add the clean script to the package.json with npm i. If i use yarn it would be great that this script runs yarn instead of npm i.

[johannesschobel]

aaaaaaaaaah.. ok, now i get it.. ok, however, i think, that may be "complex" as you need to "wrap" all those schematics to distinguish between the package manager you use. Note, that there are a few others as well (pnpm, or whatever)...

[phillipplum]

I think its only need to support this packages: npm, yarn, pnpm. When you look to nx, in this file is a package detection: https://github.com/nrwl/nx/blob/607bcfdeb28bd3d85ce03606cf1e3eeb2df53843/packages/workspace/src/utils/detect-package-manager.ts#L4

I think there is no need to support more than nx. I have not yet understood the exact structure here for a pull request.

[NathanWalker]

@phillipplum thanks for pointing this out - definitely agree, goal is to always do as little as possible for the add on's here to preserve Nx behavior in every way. I'll queue this up to resolve this and use a similar utility here. With regards to the npm scripts added on app generation mentioned by @johannesschobel we've wanted to convert most of those to Nx builder commands instead so package.json can stay slimmer which also would make the package manager switch easier.

[asciidiego]

Guys, I think a documentation is highly needed. Should I open an issue so that we can start documenting xplat as it deserves, I see many questions asked on the issues of this Github. Also, I am using xplat v8 since I am trying NativeScript and they (still) do not have Angular v9 support. Therefore, I think that a documentation per-version (such as in angular.io) could be extremely appreciated, and leveraging the power of open-source and all the individuals and companies that are using xplat, they can all fill in the gaps of knowledge for xplat.

Better documentation can only be more positive. Documentation = more adoption -> more bugs spotted / contributors. What do you think? Should I open an issue about this topic?

[NathanWalker]

Thank you @diegovincent this would be very helpful. I think the right way to explore schematics is through example commands in dry mode to see what’s effected without actually running anything and Nx Console is also a good place to try that since you can see option descriptions there. I’ll see if I can add you to the wiki although you may be able to edit there now and I can add some example commands there as a good start.

[asciidiego]

Thank you @diegovincent this would be very helpful. I think the right way to explore schematics is through example commands in dry mode to see what’s effected without actually running anything and Nx Console is also a good place to try that since you can see option descriptions there. I’ll see if I can add you to the wiki although you may be able to edit there now and I can add some example commands there as a good start.

@NathanWalker Now that you mention it... there are some commands that, when running using dry, only shows you that the command executed successfully, but it does not show the files (that would be) updated and created... so, my current workflow (when dry does not work) is make sure I am clean in terms of Source Version Control and then discard the changes safely.

[wSedlacek]

I was interested in using pnpm with XPlat and I was noticing that it wasn't quite working as I would have liked. The latest versions of Angular and NX both seem to work fine with pnpm, but when using them with xplat I am not able to start the application because dependencies of modules aren't being found.

Investigating the issue it seems that it is because of the npm install in the app directory, which isn't resolving to the pnpm format in the workspace directory. In my testing, yarn seems to resolve just fine, likely because it has a more similar structure of node_modules.

I discovered I could change the package manager that the NativeScript CLI uses with ns package-manager set pnpm which did seem to get me further, however when launching the application and the startup process running ngcc I got this error.

ERROR in Tried to overwrite /Users/william.sedlacek/Development/playground/node_modules/@angular/core/core.d.ts.__ivy_ngcc_bak with an ngcc back up file, which is disallowed.

Which lead to other errors.

Error: ../../node_modules/nativescript-ngx-fonticon/index.d.ts:5:22 - error NG6002: Appears in the NgModule.imports of PlaygroundCoreModule, but could not be resolved to an NgModule class.

This likely means that the library (nativescript-ngx-fonticon) which declares TNSFontIconModule has not been processed correctly by ngcc, or is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.

5 export declare class TNSFontIconModule {

I attempted to run ngcc manually after install but before launch the application, ie postinstall, but ngcc didn't seem to do anything when I ran it like this. It just completed without stating that it was compiling any packages. So I am kinda at a dead end until I find some sort of work around.

In any case, I think we aren't that far off from supporting other package managers like pnpm or yarn. Specifically I would like to see -

• The the schematic for a new application to use cli.packageManager to determine what to build for the clean command
• The ns CLI being set to use cli.packageManager on a given workspace (it would be ideal if this didn't change your global ns CLI config)
• Any changes needed to fix the ivy compiling with pnpm