Publishing existing npm repos to azure devops artifacts

Question

I have a private on-premise NPM repo which we would like to move away from and migrate to azure devops.

Is there a way of automatically moving the existing npm packages from the old NPM repo to the new one ?

I checked the azure devops API's but apparently there is no API which lets me publish anything in to azure devops artifacts

https://learn.microsoft.com/en-us/rest/api/azure/devops/artifactspackagetypes/npm?view=azure-devops-rest-7.2

Answer 1

You can publish your on-prem npm packages by referring this MS Document:-

1. Click on Artifacts > Select npm > Get the required tools and run the command given:-

2. Then follow the steps of Project setup:-

3. Created .npmrc file and added the above registry= code like below:-

4. Run the below command to publish the npm packages from the same directory as your package.json and .npmrc like below:-

vsts-npm-auth -config .npmrc
npm publish

5. Package got added to the Artifacts feed successfully like below:-

As a workaround you can also use azure cli to upload your packages from on-prem to Azure artifacts using the command below:-

Below command reference By Leo Liu

az artifacts universal publish --organization https://dev.azure.com/org/ --feed js --name testabc --version 0.0.1
 --description "npm packages" --path "C:\expressappp1\package.json"

Answer 2

For exactly the same purpose I created my own script (on F#) that incrementally migrates packages by downloading and uploading every version as a tgz file. The goal here is to have sha256 checksum to be intact and that way works well. Download is performed using regular REST api for npm repository, upload is done via npm publish.

The major obstacle I faced so far is that some of packages has publishConfig defined in their package.json. For such packages npm publish does not allow overriding target registry which can be clearly verified from a source code of npm utility. The only happy exception is if internal packages are published under any scope. In that case you can define registry for each particular scope, and it's not overridden. However the issue with non-scoped packages with publishConfig defined is still open.