Skip to content

Commit e7f10c1

Browse files
committed
feat(rfc): add 0000-link-dependency-type.md
1 parent 4928eab commit e7f10c1

File tree

1 file changed

+63
-0
lines changed

1 file changed

+63
-0
lines changed

text/0000-link-dependency-type.md

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
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+
# Detailed design
33+
34+
I can see two (non exclusive) ways to achieve that:
35+
36+
- Either add a new `link:` prefix that would just create symlinks and that's it
37+
(regardless of destination's existence)
38+
39+
- Add an option flag `--link-file-dependencies` that would override default
40+
`file:` handling (copying) and use symlinks instead.
41+
42+
I've already implemented the changes in yarn's [pr#1109](https://github.com/yarnpkg/yarn/pull/1109) and I'm
43+
currently maintaining a fork since my team already rely on this for several
44+
projects.
45+
46+
# How We Teach This
47+
48+
I think `link:` is pretty explicit, an update to the docs/cli-help should be
49+
enough.
50+
51+
# Drawbacks
52+
53+
Not sure how exactly cross-platform symlinks are today. However it looks like
54+
[Microsoft might be catching up](https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/).
55+
56+
# Alternatives
57+
58+
What other designs have been considered? What is the impact of not doing this?
59+
60+
# Unresolved questions
61+
62+
Not sure how we should handle actually publishing packages with such
63+
dependencies, the existing behavior for `file:` types?

0 commit comments

Comments
 (0)