Feature Request: Override initial commit hash for fallback

[aderito7]

Hi guys, was creating a new application to add to a long running monorepo.
For quick checkout we are shallow cloning the repository, which means the initial commit is never available

Could we override this with the --base input instead to avoid the following:
New version will be calculated based on all changes since first commit. ?

nx run my-app:version --base=9ce27ea49aa41772e353b4a233606aecb3554c1e --releaseAs=minor 
🟠 No previous version tag found, fallback to version 0.0.0.
New version will be calculated based on all changes since first commit.
If your project is already versioned, please tag the latest release commit with my-app-x.y.z and run this command again.
Error: fatal: bad revision 'd9c06c...
..HEAD'
    at Transform._transform (/builds/abcdefg/node_modules/git-raw-commits/index.js:84:30)
    at Transform._read (/builds/abcdefg/node_modules/readable-stream/lib/_stream_transform.js:177:10)
    at Transform._write (/builds/abcdefg/node_modules/readable-stream/lib/_stream_transform.js:164:83)
    at doWrite (/builds/abcdefg/node_modules/readable-stream/lib/_stream_writable.js:409:139)
    at writeOrBuffer (/builds/abcdefg/node_modules/readable-stream/lib/_stream_writable.js:398:5)
    at Transform.Writable.write (/builds/abcdefg/node_modules/readable-stream/lib/_stream_writable.js:307:11)
    at Socket.ondata (node:internal/streams/readable:754:22)
    at Socket.emit (node:events:406:35)
    at addChunk (node:internal/streams/readable:315:12)
    at readableAddChunk (node:internal/streams/readable:285:11)

[ianldgs]

Couldn't the first version be read from the package.json?
I'm getting the Error: fatal: bad revision after updating to NX 14.4.2 and maybe because of having run housekeeping on the repo.

[ianldgs]

@edbzn friendly ping on this!

We just got an issue (again) because gitlab ci (and other ci tools) do a shallow clone of the repo.
Some libraries were going back to 0.0.1 because the commit with the latest tag wasn't found locally (but existed in the remote).
Had to increase the depth of the git clone, which makes it slower.
Since every package causes a new commit, the more packages you have in a repo, the more likely to get errors because of shallow clone.
It's quite annoying to have to re-tag everything manually.

Allowing to read the version from the package.json would really help here.

[edbzn]

Hey @ianldgs, we don't want to make semver reading the package.json file, it would introduce more complexity and weird scenarios where the version is wrongly calculated. For example, how can we know the point from where to calculate the new version if there's no marker (tag) in the commit history? It would result in an inconsistent version calculation because it would take the whole history even if only a few commits are involved since the last release. For this reason, semver is only tag-based. It comes with cons but it's in my opinion the safest way to go.

[ianldgs]

For example, how can we know the point from where to calculate the new version if there's no marker (tag) in the commit history?

It could look at commits since --base or NX_BASE.

On branches (PRs), we set the nx base to origin/main.
On main, we set it to latest, and re-tag latest at the end of the pipeline.

[ianldgs]

So, @edbzn, what do you think? Would you accept a PR implementing this?