[rush] Internal Error reported when using "file:C:/..." as dependency version in package.json

[fuocor]

I have a package referencing a some local packages like so:

    "devDependencies": {
        ...
        "just-scripts": "file:C:/git/microsoft/just/packages/just-scripts",
        "just-task": "file:C:/git/microsoft/just/packages/just-task",
        ...
    },

when running rush update it outputs:

LINKING: @ossiaco/build                                                                                                                                                                                        

ERROR: Internal Error: Cannot find installed dependency "just-scripts" in "C:\ossiaco\etorrent\common\temp\node_modules\.local\C%3A%2Fossiaco%2Fetorrent%2Fcommon%2Ftemp%2Fprojects%2Fbuild.tgz\node_modules"  
You have encountered a software defect. Please consider reporting the issue to the maintainers of this application.                                                                                                                                                                                                                                                                                                         ```

[octogonz]

The file:C:/ scheme isn't supported. We could try to support it, but I suspect that it might have a lot of complex edge cases.

At the very least, we should probably issue a better error message, though.

[AndyLyons]

@octogonz is this true for all file: scheme dependencies, or just file:C:/? I have a package with relative dependencies like this and get a similar error:

  "dependencies": {
    "three": "1.0.0",
    "two": "file:../packages/two"
  }

[octogonz]

We should document this better. No, it's not supported. Its behavior is buggy in every package manager, and understandably so because there is no straightforward way to detect a change that requires reinstallation. Also, for this case Rush already automatically links your local projects.

[Wisedemic]

Also, for this case Rush already automatically links your local projects.

This was all I needed to read. haha

[Js-Brecht]

If the file: version specifier is not supported, then what is the recommended method for linking to a local development repository when testing?

For example, what if I fork a project and make some changes, then want to test the implementation? Normally, I would just link to that repo in one of my other projects that uses it; probably the same project I was using it in that made me realize something needed to change.

This has occurred recently, and with a package that was included as sub-dependencies in my project. In order to make sure the new version was used in all of the sub-dependencies, I used the pnpmfile.js to override the version of all of them with the file: specifier. This works if I delete the config & temp lockfiles, but as soon as I want to change any of the current dependencies, I have to delete them again, because it will throw errors.

[Js-Brecht]

I guess my issue is a little different. The error I get is this:

ERROR: Cannot parse PNPM shrinkwrap version specifier: "file:/path/to/project" for "<package>"

Separate issue, maybe?

[octogonz]

Experienced Rush users typically solve this by manually creating symlinks in the node_modules folder. For example with PNPM:

C:\> cd my-repo\common\temp\node_modules\.registry.npmjs.org\some-package\1.2.3\node_modules
C:\my-repo\common\temp\node_modules\.registry.npmjs.org\some-package\1.2.3\node_modules> move some-package some-package.old
C:\my-repo\common\temp\node_modules\.registry.npmjs.org\some-package\1.2.3\node_modules> mklink /j some-package C:\other-repo\some-package

However we've avoided documenting this, because there are complicated rules about whether it will work or not. And when you're done, you have to remember to run rush install --purge to restore a good state. It seemed too error-prone to recommend as a best practice.

Instead, something we could "officially" recommend is to add the project to your rush.json and run rush update. This solution has limitations as well (e.g. it may require --bypass-policy), but at least when it fails there will be a clear error description, and you can't get into an invalid state.

I've been wanting to offer a better solution, but I believe https://github.com/microsoft/rushstack/issues/1553 will eliminate or at least transform the problem significantly. We're hoping to have that done by end of year. It's at the top of our roadmap.

[y-a-v-a]

I've been searching the documentation but couldn't find explicitly stated that file:./dep.tgz isn't supported (it appears to be hard to search for "file dependency" as the whole site is about files and depedencies... haha). I've received a 3rd party package as dependency. Would the above imply I cannot use RushJS in this situation?

[oddball]

I have a similar problem.

I have a packages/portal/package.json

    "dependencies": {
        ...
        "@captor/quantlib-wasm": "file:../../captor-quantlib-wasm-1.19.4.tgz",

First time I do a

rush update

Everything works fine.

Second time, I get:

> rush update
Rush Multi-Project Build Tool 5.62.3 - https://rushjs.io/
Node.js version is 16.13.1 (LTS)

Starting "rush update"

Trying to acquire lock for pnpm-6.30.1
Acquired lock for pnpm-6.30.1
Found pnpm version 6.30.1 in /some_user/.rush/node-v16.13.1/pnpm-6.30.1

Symlinking "/somepath/repo/common/temp/pnpm-local"
--> "/some_user/.rush/node-v16.13.1/pnpm-6.30.1"
Transforming /somepath/repo/common/config/rush/.npmrc
--> "/somepath/repo/common/temp/.npmrc"

Updating temp projects in /somepath/repo/common/temp/projects

ERROR: Cannot parse PNPM shrinkwrap version specifier: "file:../../captor-quantlib-wasm-1.19.4.tgz" for "@captor/quantlib-wasm"

Is this not suppose to work?