Skip to content

Commit ac8f706

Browse files
mgcreaarcanis
authored andcommitted
:link dependencies (#34)
* feat(rfc): add 0000-link-dependency-type.md * chore(update): drop --link-file-dependencies from refc
1 parent 58a403f commit ac8f706

File tree

1 file changed

+64
-0
lines changed

1 file changed

+64
-0
lines changed

text/0000-link-dependency-type.md

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
- Start Date: 2016-10-12
2+
- RFC PR:
3+
- Yarn Issue:
4+
5+
# Summary
6+
7+
Add symlink `link:` dependency type to enable complex cross-project development
8+
workflows.
9+
10+
# Motivation
11+
12+
This RFC is a spinoff of yarn's [issue #884](https://github.com/yarnpkg/yarn/issues/884).
13+
14+
We've been using some kind of monorepo approach for our projects for quite some
15+
time, a bit like [lerna](https://github.com/lerna/lerna) but with a more private
16+
and nested approach (our packages aren't expected to be published for now) along
17+
some specific needs: we must to link some public dependencies (eg. mongoose)
18+
that must be the exact same instance accross our subpackages (otherwise you
19+
encounter a lot of exotic bugs, edge cases), we also link our devDeps (they are
20+
shared accross all our subpackages).
21+
22+
At first we used [linklocal](https://github.com/timoxley/linklocal) with npm@2,
23+
leveraging a custom use of the `file:` prefix (basically just symlinking them),
24+
but npm@3 broke a lot of things related to their handling (eg.
25+
[#10343](https://github.com/npm/npm/issues/10343)). We ended up moving to
26+
[ied](https://github.com/alexanderGugel/ied) where we implemented the `file:`
27+
prefix handling using simple symlinks, that tackled our need.
28+
29+
I would love to be able to switch theses project to yarn but I would need a way
30+
to create these links.
31+
32+
npm is also considering to add the same `link:` specifier, see this [recent RFC](https://github.com/npm/npm/pull/15900).
33+
34+
# Detailed design
35+
36+
We Add a new `link:` specifier that would just create symlinks and that's it
37+
(regardless of destination's existence)
38+
39+
I've already implemented the changes in yarn's [pr#1109](https://github.com/yarnpkg/yarn/pull/1109) and I'm
40+
currently maintaining a fork since my team already rely on this for several
41+
projects.
42+
43+
# How We Teach This
44+
45+
I think `link:` is pretty explicit, an update to the docs/cli-help should be
46+
enough.
47+
48+
# Drawbacks
49+
50+
Not sure how exactly cross-platform symlinks are today. However it looks like
51+
[Microsoft might be catching up](https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/) on this issue.
52+
53+
# Alternatives
54+
55+
Beside the two alternatives exposed above, I can't think of anything else for
56+
now.
57+
58+
Drawback of not implementing this is that we restrict how creative developers
59+
can be with complex multi-packages workflows.
60+
61+
# Unresolved questions
62+
63+
Not sure how we should handle actually publishing packages with such
64+
dependencies, the existing behavior for `file:` types?

0 commit comments

Comments
 (0)