Add .npmrc next to package.json and add lockfile for PublishAIEvaluationReport

[akoeplinger]

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: actions/setup-node#1305

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

This PR improves npm configuration by placing .npmrc files directly adjacent to package.json files, as npm does not transitively search parent directories for .npmrc like it does for other configuration files. The PR also removes the deprecated always-auth setting from the root configuration.

Key changes:

• Added .npmrc files next to package.json in two npm workspace locations
• Removed deprecated always-auth=true setting from root .npmrc

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/ProjectTemplates/.npmrc	New npm registry configuration for the project templates workspace
src/Libraries/Microsoft.Extensions.AI.Evaluation.Reporting/TypeScript/.npmrc	New npm registry configuration for the AI evaluation reporting TypeScript workspace
.npmrc	Removed deprecated always-auth setting while keeping registry configuration

[shyamnamboodiripad]

@peterwald Could you please take a quick look - looks like the .NET part of the build is failing

[akoeplinger]

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

[akoeplinger]

FYI @ericstj @jeffhandley this will probably conflict with #7113

[shyamnamboodiripad]

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]

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

[akoeplinger]

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.