Duplicate Tag + Release created without `v` Prefix about np HOT 10 OPEN

I suspect we'd have duplicate tags if someone manually set their tag-version-prefix. I haven't tested but let's keep open until someone can.

from np.

Thinking about it more, I now agree. We should just use npm to get the tag prefix since pnpm doesn't ship with a default v. I'm pretty sure that it's what the majority of users would want, and it's still easy enough to do npm config set tag-version-prefix '' if you don't like it.

It still must be a bug that there's a duplicate, but that's a separate, and smaller, problem.

from np.

Opened a PR for it: #739. I also think that this should be considered a bugfix rather than a real breaking change. I will try it out on another package later this week. @karlhorky you should be able to also try it by adding something like "np": "github:sindresorhus/np#pnpm-vs-npm-tag-version-prefix" to your package.json dependencies.

FYI @sindresorhus

from np.

Definitely sounds wrong that two separate tags are being created. We use pnpm config get tag-version-prefix for pnpm, which in my case is empty string, whereas npm config get tag-version-prefix is 'v'.

Might be that somewhere is hard-coding a 'v'.

Probably the easiest workaround right now is to set the pnpm config value to 'v', until it's fixed. We probably should keep the no-prefix behaviour for pnpm but definitely shouldn't have two separate tags.

from np.

Interesting, I think I may have found more information - during publishing it opens the browser to this URL, which is creating a new tag without the v prefix (2 occurrences without v here):

https://github.com/upleveled/eslint-config-upleveled/releases/new?tag=7.8.2&body=-+Switch+module+config+in+...%0A%0Ahttps%3A%2F%2Fgithub.com%2Fupleveled%2Feslint-config-upleveled%2Fcompare%2Fv7.8.1...7.8.2&prerelease=false

from np.

@mmkal maybe line 11 here?

from np.

We probably should keep the no-prefix behaviour for pnpm

Hm... my gut feel would be to add prefixes everywhere.

Seems very surprising that if I use pnpm, I suddenly get an unusual, very uncommon tag format for my releases. (I have seen v prefixes pretty much everywhere on GitHub Releases, can't remember a JS/TS ecosystem package that does not use this prefix)

Even pnpm itself uses v prefixes for their GitHub Releases + tags:

• https://github.com/pnpm/pnpm/releases/tag/v8.15.4

from np.

We probably should keep the no-prefix behaviour for pnpm

Hm... my gut feel would be to add prefixes everywhere.

I mean more that we should respect pnpm config get tag-version-prefix - ignoring the config and forcing 'v' would be a breaking change, but I guess one we could make. I'm not sure why pnpm is getting a different result from npm config get, though. Maybe that's a pnpm bug?

from np.

Yeah, good question why it's returning something different. 🤔

I would lean towards doing the change as a patch release (even if it's technically a breaking change) since the behavior feels like a bug and creates unexpected release names on GitHub.

Maybe @sindresorhus has an opinion.

from np.

Nice, I saw that #739 was reviewed and merged and released in [email protected], thanks @mmkal and @sindresorhus !

I just tested [email protected] with a project, and it's working as it was pre-v10 🎉 (no duplicate tags)

From my side, this issue could be closed, but maybe @mmkal you still have identified another issue which is why we should keep it open?

from np.