Update .npmrc approach and locked dependencies

[dougbu]

• use just one .npmrc file
• enforce resolution from correct registry in all yarn.lock files
• bump all resolved dependencies to latest compatible versions
  • re-resolve everything but don't change any package.json files

[BrennanConroy]

• use just one .npmrc file

How does that work? What is telling npm/yarn to look ~5 folders up to find the .npmrc file?

[dougbu]

This PR should reduce maintenance costs because (a) there's only one .npmrc file to change if someone wants to use a different registry locally (ignoring our lock files of course) and (b) the always-auth setting should (though supposedly no longer supported) allow local updates of the lock files to Just Work:tm: for authenticated users.

The CodeCheck.ps1 changes avoid checking in lock files using anything other than the dotnet-public-npm feed. @mmitche should something like that be part of a regular Arcade-ified build❔

@dotnet/aspnet-blazor-eng, @BrennanConroy, @halter73 the yarn.lock file changes are optional and mostly happened because I wanted to confirm always-auth was working as I expected. Please let me know if you would prefer I reverted some or all of those changes.

[dougbu]

• use just one .npmrc file

How does that work? What is telling npm/yarn to look ~5 folders up to find the .npmrc file?

I read yarn docs (somewhere) informing the world that it looked in parent directories for the .yarnrc file. Made sense it would also look up for a .npmrc file. I believe my local testing (which should have added at least a few packages / versions to dotnet-public-npm) shows this works. If there's another thing to test, I'm game…

[BrennanConroy]

Ok cool 👍 just checking

[wtgodbe]

LGTM other than the one nit

[BrennanConroy]

Remove https://github.com/dotnet/aspnetcore/blob/main/.yarnrc?

[dougbu]

Remove https://github.com/dotnet/aspnetcore/blob/main/.yarnrc?

Great idea❕ I did that and confirmed I ingested at least a few packages w/ that change in place. Went through and bumped all versions again to make sure things are still working (defence in depth). I'll push those changes (plus the two updated src/Components/Web.JS/dist/Release/blazor.*.js files) after a local build.

See https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-public-npm/Npm/@typescript-eslint%2Fparser/overview/5.52.0 for confirmation I grabbed a new package version a couple of hours ago.

[dougbu]

Anyone familiar w/ the following error❔ I' don't see problems in CI builds but it happened a couple of times in local builds when testing corner cases on this branch. Likely not important but I'd like to confirm…

...\eng\targets\Npm.Common.targets(45,5): error : "karma-sauce-launcher > webdriverio > @types/puppete
er-core > @types/puppeteer > puppeteer > puppeteer-core > [email protected]" has unmet peer dependency "mitt@*". [...\src\SignalR\clients\ts\FunctionalTests\SignalR.Npm.FunctionalTests.npmproj]

[dougbu]

Everything looks resolved and my local testing went well. I'll merge this tomorrow morning unless I get further comments in the meantime.

[dougbu]

Not merging this immediately because the aspnetcore-components-e2e pipeline is failing w/ the error I occasionally saw locally and mentioned above. See https://dev.azure.com/dnceng-public/public/_build/results?buildId=170887&view=logs&j=fe94c0c9-bb8c-5d6f-3b51-887173cc2f5c&t=7877c2d9-a5b1-59a3-dc2b-0d7e9d9db055&l=674 or

/home/vsts/work/1/s/eng/targets/Npm.Common.targets(45,5): error : "karma-sauce-launcher > webdriverio > @types/puppeteer-core > @types/puppeteer > puppeteer > puppeteer-core > [email protected]" has unmet peer dependency "mitt@*". [/home/vsts/work/1/s/src/SignalR/clients/ts/FunctionalTests/SignalR.Npm.FunctionalTests.npmproj]

One odd thing is https://www.npmjs.com/package/chromium-bidi?activeTab=dependencies shows mitt as a dev dependency. No idea why that matters in dependent code.

Another odd thing is this message shows up only as a buried warning in aspnetcore-ci jobs. Why was it an error in only the one pipeline❔

In any case, I did some searching and found the solution is found in the peerDependencies section of the relevant package.json file. Will update this PR after another local build (because I had to rebase after Tanay & @wtgodbe's #45682), likely tomorrow morning.

/cc @dotnet/aspnet-blazor-eng @BrennanConroy @halter73

[dougbu]

In any case, I did some searching and found the solution is found in the peerDependencies section of the relevant package.json file. Will update this PR after another local build (because I had to rebase after Tanay & @wtgodbe's #45682), likely tomorrow morning.

This took longer than expected because peerDependencies didn't work. Switched to devDependencies for the new mitt requirement and we're all good locally. I've enabled auto-merge (squash)…

[dougbu]

Actually, I'm building locally to see if the generated JS files need another update. Will enable auto-merge if my local build comes back clean in that area.