Version check fails if latest tag does not exist in registry

[hardillb]

I'm getting an error with v2 when trying to publish a tagged build to a GH npm repo

      - name: "publish foo"
        uses: JS-DevTools/npm-publish@v2.0.0
        with:
          tag: 'nightly'
          package: ./foo/package.json
          registry: https://npm.pkg.github.com
          token: ${{ secrets.GITHUB_TOKEN }}

Is giving the following error:

##[debug]Evaluating condition for step: 'publish foo'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: publish forge-ui-components
##[debug]Loading inputs
##[debug]Evaluating: secrets.GITHUB_TOKEN
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'GITHUB_TOKEN'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Loading env
Run JS-DevTools/npm-publish@v2.0.0
  with:
    tag: nightly
    package: ./foo/package.json
    registry: https://npm.pkg.github.com/
    token: ***
::add-mask::***
##[debug]Temporary .npmrc created at /home/runner/work/_temp/npm-publish-vT2pRJ/.npmrc
##[debug]; created by jsdevtools/npm-publish
##[debug]//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
##[debug]registry=https://npm.pkg.github.com/
##[debug]
##[debug]Running command: npm view --ignore-scripts --json @flowforge/forge-ui-components dist-tags versions
Error: TypeError: Cannot read properties of undefined (reading 'nightly')
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: publish forge-ui-components

If I setup my an equivalent .npmrc file locally and run

npm view --ignore-scripts --json @foo/foo dist-tags versions

it returns an empty string implying that the GH npm repo doesn't support the npm view command

I'm guessing this is to do with it trying to check the version for stagegy changes in v2.

Is there anyway to stop it doing this check? The release notes imply not and to use npm directly (but that means having to do all the .npmrc setup manually which is why I was using the action in the first place.

I'm going to roll back to v1 for now, but that is not a long term solution.

[mcous]

Thanks for the report! Looking into it.

Is there anyway to stop it doing this check? The release notes imply not and to use npm directly (but that means having to do all the .npmrc setup manually which is why I was using the action in the first place.

The GitHub maintained actions/setup-node action will setup the .npmrc file for you if you use the registry-url option. If you do not need version checking, you should use that functionality instead, as detailed in GitHub's documentation: https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages

[mcous]

@hardillb so far I'm having trouble reproducing this issue with my own packages nevermind, see update below. npm view seems to work on my end with the GitHub Package Registry:

• If not authorized, I correctly get a 401 error
• If package does not exist, I correctly get a 400 error
• If package exists, npm view ... returns dist-tags and versions

Using npm view to check for existing versions is not new (default) behavior for v2, it's just the option name that changed, so I'm curious to know how v1 is working. Is the repo you're experiencing this issue with open source? If so, would you mind linking me to run logs where this failure happened? The debug logs you attached mentioned @flowforge/forge-ui-components, but I didn't see any sort of failures in the publicly accessible action logs for that repo.

Clearly something is up, because you shouldn't be able to hit the version comparison logic with dist-tags as undefined, so any extra information you're able to provide would be really helpful

---

Update: the key here seems to be the lack of a latest tag! This may be a regression introduced between v1 and v2 with how npm view is called

[hardillb]

Hi,

The action is run as part of the flowforge/CloudProject which is private (and unfortunately currently can not be opened up).

The repo is only used for our staging builds to provide early access and nightly builds of components before pushing to our staging environment. As you have noted none of the packages in the repo have a latest tag, but I could probably tag a version with that if it will help as a workaround.

[mcous]

@hardillb thanks for the follow up, that makes sense. I have a solid repro locally using one of my own packages, so I think I'm good to move forward here. I have filed npm/cli#6408 for the "no latest tag" issue with npm, but even if they fix it, it'll still need to be worked around here. This problem does not occur on the public npm registry because, unlike the GitHub registry, npm will always create a latest tag for a new package.

I think your existing workaround of sticking with v1 of this action (which does npm view package@tag) is the best course of action for now. npm view package@tag has the downside of potentially hitting #35 for a fresh tag when latest does exist, which hopefully isn't an issue with your workflow, but makes it a bit tricker to fix in the general case.

Two ideas right this second:

1. Perform a separate call to npm dist-tags <package_spec> before calling npm view
2. Check for the "empty output" failure specifically, and make a follow-up call to npm view pacakge@tag

[mcous]

Fix has been merged, I am planning on releasing as part of v2.1.0 tomorrow morning, eastern US time