Look up the release under the tag changesets actually creates

[enyo]

The 6.2.1 publish succeeded on npm and then failed on the last step, attaching dist.zip, with release not found against v6.2.1.

Why

Changesets only prefixes a tag with v for a single-package repository. From @changesets/cli:

function buildGitTag(tool, { name, version }) {
	return tool.type !== "root" ? `${name}@${version}` : `v${version}`;
}

tool.type is "root" only when there is no workspace. Becoming a pnpm workspace therefore moved the tags to dropzone@<version> with nothing announcing it, while this step went on asking for v<version> — a release that had never been created. I introduced that mismatch in #2353.

The step now builds the tag from the name and version the action reports, which are the same two values changesets used.

Keeping the <name>@<version> scheme

Restoring v<version> would mean taking tagging away from the tool — create-github-releases: false, push-git-tags: false, and roughly twenty lines here to create the tag, extract the version's section out of CHANGELOG.md for release notes, create the release and attach the asset. That is code reimplementing what the action already does, and the notes formatting would be free to drift from it.

Nothing functional depended on the v prefix:

• npm, unpkg, jsDelivr /npm/ resolve from the registry
• Packagist reads the mirror's tags, not this repo's, and the mirror now derives v<version> from whatever upstream calls its tag — enyo/dropzone-packagist@9bca440
• jsDelivr /gh/ addresses the tag fine, it is just spelled with two @. Verified against the live tag: cdn.jsdelivr.net/gh/enyo/dropzone@dropzone@6.2.1/packages/dropzone/package.json returns 200 and reports 6.2.1, while the same path at @v6.2.0 returns 404
• the only references in either repository are two CHANGELOG lines pointing at v5.9.3, which are history and unaffected

What remains is cosmetic — dropzone@6.2.1 sits above v6.2.0 on the releases page — and it is the scheme that stays correct if this repository ever publishes a second package.

6.2.1

dropzone@6.2.1 is published on npm and its GitHub release exists but has no dist.zip, because that is the step that failed. Attaching it by hand is the remaining repair, and the mirror fix had to land first: until it did, the next hourly sync would have tagged the mirror dropzone@6.2.1 and made the release invisible to composer.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	79.42%	880 / 1108
🔵	Statements	79.77%	927 / 1162
🔵	Functions	92.89%	196 / 211
🔵	Branches	76.46%	510 / 667

File Coverage

No changed files found.

Generated in workflow #124 for commit 121930a by the Vitest Coverage Report Action