Azure-pipelines-tasks: NPM Publish Allow specifying tags or lack of for latest

[Lokiem]

Currently anything getting published to an private internal feed will get the "latest" tag creating a problem when allowing for prerelease and release versions.

My current setup has an internal feed which local repos publish to, and a second feed with an upstream to the internal feed and to npmjs, if I use the upstream internal@local then latest will usually be a prerelease, internal@release and I can't install prerelease, using both internal@prerelease and internal@release then I have to specify exact versions to avoid prerelease versions.

I think this would be solved by allowing us to set the tag/s on the task.

[jotaylo]

As a workaround, you could set the build variable/environment variable npm_config_tag to the desired value before running the publish.

Keep in mind that internal@release and internal@prerelease refer to views, not tags. Packages of any package type need to be promoted into those views, npm packages are not added to the views just by being tagged.

[Lokiem]

I revisited this issue today, and you can't set environment variables against the npm task.

I set npm_config_tag as a pipeline variable and it was ignored, I read that variables set in the pipeline can be used by subsequent tasks, so I set it in a command line task before the publish and it was still ignored.

I added publishConfig: { tag: "prerelease" } to the package.json and tried it again, I see it listed in the log under "; environment configs" with "tag: "prerelease"" but an npm install still picked up the prerelease tagged package as the latest.

I'm not sure if I'm going about it the wrong way, but it feels like the task ignores any config you provide and sticks latest on everything?

[Lokiem]

I removed the NPM task from the equation and just used the NPM authenticate task and manually set the package feed in .npmrc running the npm publish --tag=prerelease in command line afterwards and it -still- ends up being tagged as latest despite explicitly stating a different tag.

So this isn't specifically a problem with the NPM task, but a fundamental problem with NPM feeds in Azure DevOps, unless I'm doing something wrong? I would think tagging packages is a fairly commonplace thing, so I'm inclined to think I'm doing something wrong.

Attempted:

• npm_config_tag pipeline/environment variable
• Set npm_config_tag variable in a task before the npm task
• publishConfig { tag: "tagname" } in package.json
• Used the NPM Authentication task and ran npm publish --tag=tagname (Might not matter, but also tried --tag tagname) in a following command line task

[jotaylo]

It looks like you're doing it right, it works for me. If this is the first time the package is getting pushed, it will be tagged with both latest and the tag, and all subsequent versions with just the tag.

c:\>npm publish --tag=prerelease
+ [email protected]
c:\>npm dist-tag ls npmt7
foo: 10.8.13
latest: 10.8.12
prerelease: 10.8.14

Which version of node/npm are you using?

[Lokiem]

I was running the publish from the Hosted Ubuntu agent (https://github.com/Microsoft/azure-pipelines-image-generation/blob/master/images/linux/Ubuntu1604-README.md) so it has Nodejs v10.15.1, not sure which version of npm it has.

I tried npm dist-tag ls packagename and it only ever listed latest, even npm dist-tag add packagename prerelease didn't seem to do anything, npm dist-tag ls packagename would still only say latest.

Trying to publish from my own machine appears to work fine. This is bizarre, would you be able to check a publish via the hosted ubuntu agent with your own setup? The same command that works from my own machine doesn't appear to be tagging correctly via the release process on VSO.

[jotaylo]

Can you email me (removed) with the name of your organization (dev.azure.com/organization) and the feed name/package name. I'd like to look at the logs to see if there's something unexpected going on.

[infin8x]

@Lokiem @jotaylo was this resolved?

[Lokiem]

@alexmullans The original request for specifying tags on an npm publish is still a valid feature request.

My specific issue landed on situational issue between multiple feeds, tags between an upstream feed and a source feed are lost and everything is marked as latest. So it's somewhat of a bug / a known technical debt during implementation of feeds in Azure DevOps. There isn't a clean solution to my specific issue as discussed in this, best workaround is to publish directly to the source feed which will keep any tags intact, though hardly ideal.

[guillermotti]

@jotaylo any news on this?

I have connected the npm service under Service Connections but I'm not able to publish a npm package to npm public registry with a tag like this:

task: Npm@1
    inputs:
      command: 'custom'
      workingDir: 'lib/dist'
      verbose: true
      customCommand: 'publish --tag alpha'
      customRegistry: 'useNpmrc'
      publishEndpoint: 'NpmJs'

It seems that this is working just if the command is 'publish' instead of 'custom', but nothing is tagged and the package is going to be published as latest.

I think you should include an option for the inputs to tag a version when the command is 'publish'.

[mrtristan]

@Lokiem i was facing the same issue. what i wound up with in my debugging was this:

- task: PowerShell@2
  displayName: 'Publish'
  inputs:
    targetType: 'inline'
    script: |
      # https://github.com/microsoft/azure-pipelines-tasks/issues/9743
      if("$(buildtag)" -ne "") {
          write-host "publishing using tag [$(buildtag)]"
          npm publish --tag "$(buildtag)"
      }else {
          write-host "publishing without a tag"
          npm publish
      }
    failOnStderr: false
    pwsh: true

this was not working which lead me to this thread. upon seeing the comment by @jotaylo, i noticed that the only real difference was the missing = in the tag assignment. i just added that and it _seems_ to be working. going to have my front end devs validate and then i'll report back but in my quick test i was seemingly able to pull a package by the tag.

seemingly working:

- task: PowerShell@2
  displayName: 'Publish'
  inputs:
    targetType: 'inline'
    script: |
      # https://github.com/microsoft/azure-pipelines-tasks/issues/9743
      if("$(buildtag)" -ne "") {
          write-host "publishing using tag [$(buildtag)]"
          npm publish --tag="$(buildtag)"
      }else {
          write-host "publishing without a tag"
          npm publish
      }
    failOnStderr: false
    pwsh: true

[woppa684]

My specific issue landed on situational issue between multiple feeds, tags between an upstream feed and a source feed are lost and everything is marked as latest. So it's somewhat of a bug / a known technical debt during implementation of feeds in Azure DevOps.

@Lokiem Where did you get this info? We're experiencing the same thing in our company and it's really bugging our process here... This thread is the only place where I can find something that looks alike our issue.

Currently it seems the only way to move forward is by directly pushing to our "merge feed" that merges everything we develop ourselves and the packages coming from npmjs....

[japj]

we are experiencing the same issue and have also reported this at https://developercommunity.visualstudio.com/content/problem/783921/published-npm-package-in-upstream-internal-feed-lo.html

[jotaylo]

Yes, views/upstreams don't support dist-tags. The most recently added package will be tagged as 'latest', but no other dist-tags are maintained.

This is partially due to a limitation with our current implementation of views - we would need a redesign to be able to support the additional metadata required for dist-tag support at view level. We originally discussed simply passing through dist-tags to views, however that lead to all sorts of issues. A dist-tag could disappear from a view if the dist-tag was moved to a version that isn't in the view. If a feed has multiple upstream sources, how should different versions with the same dist-tag be resolved. We've had some discussions on these issues, but do not plan any changes in the short term.

[cotyhamilton]

@jotaylo How are we supposed to views appropriately then? No matter which view an npm package sits in, it's always the 'latest' package that gets installed, no matter which permissions are set in the views.

Edit:

So I've figured out how this works now. The views are treated as separate registries. To use the prerelease view for example, the registry looks like: https://pkgs.dev.azure.com/<organization>/_packaging/<feed name>%40Prerelease/npm/registry/

To find this, you click on the view you want to use first, then select connect to feed.

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days