[rush] links are not created if the package.json dependency version is an NPM release tag

[ghost]

Is this a feature or a bug?

• Feature
• Bug

Please describe the actual behavior.

When running rush install or rush update --full --purge, rush does not create symlinks to the local projects, if those projects are referenced as "latest" version.

If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.

An example of such package.json:

"dependencies": {
  "some-module-from-repository": "latest"
}

When installing through rush install it does create the following package.json in rush folder:

"some-module-from-repository": "latest",
"@rush-temp/some-module-from-repository": "file:./projects/some-module-from-repository.tgz",

I believe this is not an expected output and should be only the one that is referenced to @rush-temp.

What is the expected behavior?

It should create a symlink, not the install the latest version.

If this is a bug, please provide the tool version, Node.js version, and OS.

• Tool: Rush
• Tool Version: 5.27.1
• Node Version: v12.18.1
  • Is this a LTS version? Yes
  • Have you tested on a LTS version? Yes
• OS: MacOS

[octogonz]

latest is not a valid SemVer range. Can you use * instead?

[ghost]

Hm... true. I just checked and if using * instead of latest it resolves the issue. Is this a common practice to reference the latest versions like this? Is there any unfortunate side effect?

The problem I'm solving is that I need to reference to the latest accesible version and still have all the Rush features.

[apostolisms]

If using * doesn't fully solve this, another workaround would be to use exact local version and use rush version --bump to apply the changes in the change files.

There is no option in Rush to replace * with an exact version while publishing if that is something you are looking for but #1938 might be a better all-around solution if you are willing to switch to pnpm workspaces.

[ghost]

No, I don't need a publish feature from Rush. There is some legacy CI system built in company that is responsible for sparse checkout and calling npm install and stuff. They are responsible for all the versions bump, etc...

My goal is to simplify a life for our team when working locally with the project in mono repository. So, our workflow:

• git clone
• rush install, update, build, test, lint, etc... (other custom commands)
• git push

Nothing that is required to bump versions or handle their versions. Although, we want to have a latest version, because the CI system always publishes a new versions and we don't want to spend every few hours updating them at our package.json.

[octogonz]

@apostolisms Rush should probably report an error to clearly communicate that latest is not supported.

Or, if latest is equivalent to *, we could simply substitute the string when generating the common/temp packages.

Either of these solutions would probably be a pretty quick PR for someone to turn around.

[ghost]

AFAIK, latest is a tag that pins an exact version. So if you have a different channel distributions, like latest, rc, beta, etc. it can hurt those who expect to get version from tag latest, not the latest avaialbe.

So, when developers write latest they expect to get version from tag latest, while latest available version is semantically another construct and AFAIU * is the one to get the latest available version (even if it is in beta channel or something).

Just a warning that latest breaks symlinking features is enough, at least it will be explicitly stated.

[octogonz]

AFAIK, latest is a tag that pins an exact version. So if you have a different channel distributions, like latest, rc, beta, etc. it can hurt those who expect to get version from tag latest, not the latest avaialbe.

Oh right. Rush should support that.

[octogonz]

This is probably a bug with the cyclicDependencyProjects SemVer check here:

rushstack/apps/rush-lib/src/logic/InstallManager.ts

Lines 256 to 268 in 4318009

	if (localProject) {
	// 2. If it's a symlinked local project, then it's not a candidate, because the package manager will
	// never even see it.
	// However there are two ways that a local project can NOT be symlinked:
	// - if the local project doesn't satisfy the referenced semver specifier; OR
	// - if the local project was specified in "cyclicDependencyProjects" in rush.json
	if (
	semver.satisfies(localProject.packageJsonEditor.version, dependency.version) &&
	!cyclicDependencies.has(dependency.name)
	) {
	ignoreVersion = true;
	}
	}

We proposed to improve this logic in issue #547 .

The same topic also came up with @D4N14L 's PR #1938 for supporting PNPM workspaces, where he introduced the workspace: prefix to explicitly control whether a project is locally linked or not.

If someone has time to think through the details, I feel like a small fix would probably connect the dots and close both #547 and #1977.

[ghost]

I just ran a check on semver.satisifes code and got an interesting result.

So, if you have a package A with a version "1.0.0" and package B that references the package A with "latest", semver responds with false:

const semver = require("semver")
console.log(semver.satisfies('latest', '1.0.0')); // false