Minor annoyances using the file: protocol

[srmagura]

I mainly use workspaces to link packages together, but sometimes I want a package outside my workspace to access one of the packages in the workspace. For this, I use the file: protocol e.g.

"dependencies": {
    "@interface-technologies/iti-react": "file:../iti-react"
},

Slow resolution step

I created a simple repository to test resolution performance using the latest Yarn (3.0.2). sample-package depends on @interface-technologies/iti-react via the file protocol. I'm using my iti-react package as an example of a typical small JavaScript library.

When running yarn install in sample-package, the resolution step took 1m 23s for the initial install and around 40s for subsequent installs (with nothing actually changed). On my Mac which is newer, it was faster but still about 40s for the initial install. I've seen even longer resolution times (over 3 minutes) when using file: in larger repositories.

Checksum in lockfile changes frequently

When using file:, I've also noticed the checksum of the package that's referenced via file: will change when "nothing" has actually changed with the referenced package or its dependencies. For example, when I cloned my yarn-resolve-repro repository on my Mac and ran yarn install in both packages, the checksum of the iti-react dependency changed. Nothing else in my yarn.lock was changed by the install.

This behavior creates "churn" in the lockfile and also prevents me from using immutable installs in CI because the checksum will be different between my dev machine and the CI environment.

---

This isn't really a question or a bug report, I guess I just wanted to document these little annoyances. Neither of these things are roadblocks for me, but if Yarn could improve upon these pain points in the future, that would be awesome.

[merceyz]

For this, I use the file: protocol e.g.

If you don't need to pack the target into the cache you should use portal: instead which doesn't suffer from the checksum issue

[srmagura]

Finally got around to using portal: and it appears to have solved both issues! Thank you.