chore: sync @snyk/fix version in CLI with release

[ghost]

We currently run update-versions.sh during release to replace all 1.0.0-monorepo references to the next version being released. So the @snyk/fix version in the CLI's package.json should also be 1.0.0-monorepo so that it's replaced at the same time too.

To Do

• We currently use npm@6 in various cases to install production deps for testing. That should not be needed.
  • https://app.circleci.com/pipelines/github/snyk/snyk/5567/workflows/76ce080e-4312-421f-a17c-af22a184b56b/jobs/35919

@snyk/fix and CLI need to be kept compatible within individual PRs.

Since the npm 7 symlinks dependant workspaces we are mostly testing CLI with the local @snyk/fix rather than whatever version is in the root package.json.

$ cat package.json | fgrep @snyk/fix
    "@snyk/fix": "1.620.0",

$ cat packages/snyk-fix/package.json| fgrep version
  "version": "1.0.0-monorepo",

$ ls -la node_modules/@snyk | grep snyk-fix
lrwxr-xr-x    1 jahed  staff     23 25 May 11:12 fix -> ../../packages/snyk-fix

Currently, without this PR, we are testing with a local @snyk/fix and then publishing with a different, older version. Only after we bump that version in the root package.json will we be publishing with the version we're actually testing with.

So it makes sense to keep versions in sync and compatibility is maintained within individual PRs.

[github-actions]

	Fails
🚫	Commit "wip: check what happens" is not a valid commitizen message. See Contributing page with required commit message format.

	Messages
📖	This PR will not trigger a new version. It doesn't include any commit message with feat or fix.

Generated by 🚫 dangerJS against ab99350

[lili2311]

@jahed-snyk for the changes that require both CLI and lib changes we would now have to raise it in the same PR after this change?

[ghost]

@jahed-snyk for the changes that require both CLI and lib changes we would now have to raise it in the same PR after this change?

Yes, however it'd be a temporary step until we decide how to properly integrate Lerna's release process. This PR is just experimenting with what routes we can take to avoid double deployments and speed up time-to-release. I don't plan on merging (there are issues with our current CI pipeline) but I'll share my findings in the future to discuss.

[ghost]

Closing as CLI bundling resolved this. #2105