dotnet
Add .npmrc next to package.json and add lockfile for PublishAIEvaluationReport
The .npmrc is not transitively looked up in parent directories like other config files, it needs to be next to the package.json
Add a lockfile for PublishAIEvaluationReport and make sure we're using npm ci instead of npm install everywhere so that we only restore the dependencies but not upgrade them.
Also remove the always-auth entry since it is deprecated/unused in npm and will be removed: https://github.com/actions/setup-node/issues/1305
Microsoft Reviewers: Open in CodeFlow
@peterwald Could you please take a quick look - looks like the .NET part of the build is failing
@shyamnamboodiripad the failure was actually related, I found that you ran npm install as part of the build, but that will fetch the latest versions of dependencies which will not work without authentication to the dotnet-public-npm feed (it would need to ingest packages from the upstream feed).
Using npm ci so that it only restores whatever is mentioned in package-lock.json avoids that and allows an anonymous restore.
One wrinkle is that whenever you actually want to bump versions you need to do that locally with an authenticated user for the dotnet-public-npm feed so that it ingests the packages. And one more issue is that npm by default only fetches the optional dependencies for e.g. esbuild or rollup for the current platform (e.g. @rollup/rollup-win32-x64-msvc), so if you restore on Windows it will only ingest those matching packages which won't be enough on Linux/Mac.
aspnetcore uses this script to manually fetch optionalDependencies: https://github.com/dotnet/aspnetcore/blob/a9aaa320f1c4c771b2dee8c000409a5f04397339/eng/scripts/update-npm-dependencies.ps1#L45-L63, I used a modified version of that to get both rollup and esbuild. I can port it here if you want.
FYI @ericstj @jeffhandley this will probably conflict with https://github.com/dotnet/extensions/pull/7113
Thank you @akoeplinger.
One wrinkle is that whenever you actually want to bump versions you need to do that locally with an authenticated user for the dotnet-public-npm feed so that it ingests the packages
I may be wrong, but I think it was already the case that we had to update the lock file manually when updating packages. (For example, I remember some of the dependabot created PRs for bumping dependency versions would fail without cloning the bot's branch and running the build locally to update the lock file...) So, this sounds reasonable.
And one more issue is that npm by default only fetches the optional dependencies for e.g. esbuild or rollup for the current platform (e.g. @rollup/rollup-win32-x64-msvc), so if you restore on Windows it will only ingest those matching packages which won't be enough on Linux/Mac.
Ah interesting... Is this a limitation only with npm ci or was that also the case before for npm build?
aspnetcore uses this script to manually fetch optionalDependencies: https://github.com/dotnet/aspnetcore/blob/a9aaa320f1c4c771b2dee8c000409a5f04397339/eng/scripts/update-npm-dependencies.ps1#L45-L63, I used a modified version of that to get both rollup and esbuild. I can port it here if you want.
Yes, given the above limitation, it seems like a good idea to port it. Thanks! That said I would defer to @peterwald who is more familiar with the build authoring and publishing for the JavaScript assets in the evaluation reporting library - especially the changes in the Azure DevOps extension that are also happening in this PR. @peterwald Could you please review?
@peterwald Could you please take a quick look - looks like the .NET part of the build is failing
Thanks @shyamnamboodiripad. These changes look good to me.
Ah interesting... Is this a limitation only with npm ci or was that also the case before for npm build?
Yes this was already the case with npm install before, but you never noticed it because due to the missing .npmrc it just pulled from registry.npmjs.org instead of the AzDO feed. I'll port the script.