Yarn: Issue: yarn workspace dependencies on unpublished repositories

[cgestes]

What is the current behavior?
[ I am willing to help fixing, but I would need some guidance ]

Basically it boils down to being able to link to unpublished repositories locally. If more than one link is made to an unpublished repository, yarn starts issuing warnings.

I tried with either:
'dep' : 'file:../dep'
'dep': 'link:../dep'

I made a simple repository, with 3 packages a, b, c.
b depends on [a]
c depends on [a, b]

Putting link: in the package.json of b to depends on a produce a warning.
Putting file: produce folders (not symlinked): packages/b/node_modules/a

(also... the correct symlinked folders are available at root/node_modules/{a,b,c})

A simple fix to that (but then eslint and other tools complains) is to simply not put the dependencies in packages/b and packages/c. Then the default created symlinks will ensure everything work as expected.

If the current behavior is a bug, please provide the steps to reproduce.

Simple test case to reproduce:

git clone https://github.com/cgestes/yarn-workspace-link-issue
cd yarn-workspace-link-issue
yarn
yarn install v1.3.2
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
warning Pattern ["a@link:packages/a"] is trying to unpack in the same destination "/home/ctaf/.cache/yarn/v1/npm-a-1.0.0" as pattern ["[email protected]"]. This could result in a non deterministic behavior, skipping.
warning Pattern ["b@link:packages/b"] is trying to unpack in the same destination "/home/ctaf/.cache/yarn/v1/npm-b-1.0.0" as pattern ["[email protected]"]. This could result in a non deterministic behavior, skipping.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 0.18s.

What is the expected behavior?
No warnings. Only the needed symlinks.

Please mention your node.js, yarn and operating system version.
Linux 4.13.8-1-ARCH #1 SMP PREEMPT Wed Oct 18 11:49:44 CEST 2017 x86_64 GNU/Linux
yarn 1.3.2
node 8.8.1

[connectdotz]

@cgestes if a/b/c are workspaces, i.e. configured as yarn workspaces, wouldn't it "just worked" without any "file" or "link" prefix? you should be able to treat them like any external-package dependency...

[ghost]

I ran into same problem with file: dependency.

I have an unpublished package (say, unpublished-pkg) in my monorepo. Other packages depends on it with "file:./some/reltive/path. unpublished-pkg is in _yarn workspaces_ as well as its dependants. Yarn workspaces are enabled.

E: on yarn install somewhere in workspace, I assume my unpublished-pkg will be linked in root node_modules and all dependants will read this linked source.

A: on yarn install the unpublished-pkg is linked in root node_modules as expected, but every dependant makes non-linked copy of umpublisked-pkg in its own node_modules, therefor, imports from unpublished-pkg are resolved from local hard copy, instead of root link.

I assume this is common behavior for non-npm packages, because ~my github linked packages also always creates copy in local node_modules~ (EDIT: actually, some github packages are hoisted). This behavior breaks yarn workspace link feature.

In other words, since (some) non-npm packages are not hoisted, workspace link not works for them.

[garytryan]

I am also using workspaces and I'm getting the same results that @vclav is describing.
I would also expect that when a workspace depends on another workspace it will use a symlink to the hoisted symlink in the roots node_modules.

Additionally the bin behavior does not seem to be working as I would expect. I would expect the symlinks to be setup for the bin executables also, as is describe for NPM links.

[arcanis]

A reproduction repository would go a long way to help me understand what's the problem you're experiencing 🙂

E: on yarn install somewhere in workspace, I assume my unpublished-pkg will be linked in root node_modules

I would also expect that when a workspace depends on another workspace it will use a symlink to the hoisted symlink in the roots node_modules.

Please don't expect anything from the hoisting. It's an optimization, an implementation detail, not something you should rely on.

[w4-hojin]

https://github.com/yarnpkg/yarn/issues/4812

"dependencies": {
"dep": "0.1.0",
},

"resolutions": {
"dep": "link:../dep"
}