Move back to NPM

[javiercn]

Nodejs 16 ships with NPM 7 which solves a lot of the issues with previous versions of NPM (speed, reliability, shared dependencies) and offers a way for us to manage our shared dependencies centrally. We agreed on DoI to give this a try and report back.

[BrennanConroy]

FYI, we would lose the resolutions feature of yarn https://stackoverflow.com/questions/52416312/npm-equivalent-of-yarn-resolutions, looks like if we add a dependency to another third-party package we can get similar behavior.

[dougbu]

What's the implication of that loss @BrennanConroy❔

More generally, @javiercn and @BrennanConroy is this something the Blazor or SignalR teams should own and fix❔ Would rather not leave unassigned area-infrastructure issues around, especially if they're not visible in one of our projects.

[javiercn]

@BrennanConroy NPM now also has resolutions FYI.

@dougbu sure, lets come up with some way to hide them from your projects.

[dougbu]

@dougbu sure, lets come up with some way to hide them from your projects.

@javiercn @wtgodbe and I don't triage assigned issues or those on the DoI project board. Putting this on someone's plate or that project board would help 😸

[dougbu]

@mkArtakMSFT @rafikiassumani-msft who should this be assigned to❔

[wtgodbe]

Any update on this @mkArtakMSFT @rafikiassumani-msft?

[wtgodbe]

@javiercn assigning this one to you as you said you'd be starting on this.

[javiercn]

We have been wanting to move back to npm for a while for several reasons:

• Comes built-in with NPM.
• Centralized dependency versions.
• We can get rid of npmproj and companion SDK.
• Makes our life easier with source build.

I took a stab at it today during my build ops rotation and actually managed to make some significant progress.

You can run npm install at the root of the repo and it'll restore all the projects.
You can run npm run build --workspaces --if-present and it will run the build script for those apps that have it.

Over the course of doing this I took several shortcuts:

• Removed the @microsoft/dotnet-js-interop package.
  • We are the only ones that consume it and we do not push it to npm.
• Changed packages to use npx instead of invoking the script from node_modules.
• Had to adjust some paths in other tools too.
• I had to disable the .npmrc because it did not allowed me to restore locally.
• Some other things in the build output have changed paths and I have adjust them to continue going.
  • We should ideally produce the same output or have a good understanding
• I disabled the signalr functional tests because I could not get them to work.

You can see the changes in this branch:
https://github.com/dotnet/aspnetcore/tree/javiercn/move-to-npm

Stuff that I have not done:

• I have not integrated this with our build system.
• I have not moved the common dependencies to the project on the root.
• I have not integrated the project-to-project references via typescript project references.
• I have not figured out the dev experience, other than you run a command at the root of the repo to build and produce the appropriate outputs.
  • This npm run build --workspace path/to/package.json.
  • Its easy enough for us to add scripts at the workspace package.json to trigger individual builds parts.

At this point, I think we can start working on the remaining things little by little until we can do the switch.

[BrennanConroy]

Removed the @microsoft/dotnet-js-interop package.

• We are the only ones that consume it and we do not push it to npm.

https://www.npmjs.com/package/@microsoft/dotnet-js-interop?activeTab=versions

[dougbu]

I had to disable the .npmrc because it did not allowed me to restore locally.

This is a significant problem and means your changes must not be checked in. If your experiments w/ vsts-npm-auth are also not working, the workaround (which will break the experiments I requested in our Build channel) is likely to add always-auth=true to the .npmrc files at least temporarily.