Release tagged 7.3.2 doesn't correspond to main branch in repo and doesn't include some recent work

[robations]

trafficstars

I was investigating a problem that appears to be fixed in 7.3.2 (relating to semver changes), but the built code doesn't include this work.

For example:

# node_modules/gatsby-source-sanity/package.json
{
  "name": "gatsby-source-sanity",
  "description": "Gatsby source plugin for building websites using Sanity.io as a backend.",
  "version": "7.3.2",
  "author": "Sanity.io <[email protected]>",


# node_modules/gatsby-source-sanity/lib/util/createNodeManifest.js (line 12)
const gatsbyVersion = (0, gatsby_core_utils_1.getGatsbyVersion)();

# node_modules/gatsby-source-sanity/src/util/createNodeManifest.ts (line 11)
const gatsbyVersion = getGatsbyVersion()

# https://github.com/sanity-io/gatsby-source-sanity/blob/be63b870fcddc5969337a2342670a26a1aeaee1b/src/util/createNodeManifest.ts#L11
# (actual 7.3.2 release in this repo)
const gatsbyVersion = version

Notice that the 7.3.2 tag (55af10) isn't actually the one on the main branch which is be63b8. Note the warning message on the tag:

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

As 7.3.2 (as published on npm) is missing some important changes, can this be republished from the actual commit on the main branch in this repo?

I'm fairly sure this is an innocent mistake, but this sort of thing makes me nervous about the npm ecosystem and accountability between built/published packages and what is visible in the open source. Are there any process improvements that could prevent this happening, such as automating npm publish based on tagged commits?

[robations]

@hdoro I think this was your publication? Is it possible to sync with the main branch and republish a new version?