Rules_nodejs: Yarn 2.0 support

[Toxicable]

Yarn 2.0 has been released. https://dev.to/arcanis/introducing-yarn-2-4eh1
This release has some massive changes, the biggest one is using PnP by default. https://next.yarnpkg.com/features/pnp
However, we can disable the use of this with a pluin for a first cut, then later on aim to support PnP.

The migration guide is here https://next.yarnpkg.com/advanced/migration
From what I can see, with keeping node_modules, there aren't too many big changes, needs more investigation.

[pauldraper]

PnP is pretty neat, as it allows strong flexibility in linking, giving better performance.

I actually thing it could be appealing to use in rule_nodejs for everything.

[payload]

How would this be done? As far as I understand .pnp.js resolves paths. Would this script be queried to generate build files?

[ashi009]

.pnp.js's approach to the package resolution is quite similar to the rules_nodejs's, or to say, the right way to handle package resolution.

Apart from the pnp, a few things that I want from yarn 2 are:

• portal: support, to allow absolute package lookup in the workspace without any post-install magic
• patch: support, to replace patch-package
• install @types automatically

I guess adopting yarn2 is not easy, as all the existing rules are built around the node_modules assumption and many need to be rewritten to take advantage of the pnp. On the other hand, support yarn 2 and drop the support of npm and yarn 1.x in the next major release will significantly simplify some rules implementation, eg. nodejs_binary and ts_library, given the efforts that facebook are put into to make pnp work on all major libraries, including typescript.

[Toxicable]

@ashi009 I've done a small prototype here https://github.com/bazelbuild/rules_nodejs/pull/1856 and you're right it makes the implementation of the rules in this repository simple.
However there are still a few issues im not certain about.

• Are we able to replace replicate all nodejs_binary's with yarn2_nodejs_binary?, are there edge cases I might have missed?
• How does a global cache work with remote execution? does it force you to use "Zero Installs"?
• What is the general community support for yarn2? Would a user face an issue with yarn2 that they wouldn't with pure node?
• How would it work with the rest of this repository? There's no chance of only supporting yarn2 alone so we'd need to support 2 methods of executing a nodejs program

I havn't had much time to work on it lately so im open for any contributions here

[ashi009]

@Toxicable I have answers to some of those (I guess):

• How does a global cache work with remote execution? does it force you to use "Zero Installs"?

Probably like how rules_go handles this. Install dependencies in a repository rule declared directory and cache those files. But I guess it's not particularly remote execution friendly.

• What is the general community support for yarn2? Would a user face an issue with yarn2 that they wouldn't with pure node?

Let facebook deal with that, they are staffed to roll yarn2 forward.

• How would it work with the rest of this repository? There's no chance of only supporting yarn2 alone so we'd need to support 2 methods of executing a nodejs program

I don't think supporting both sound. After all, people will only keep either package.lock, yarn.lock or the new yaml yarn.lock in a single workspace. If yarn2 was the chosen one (I hope), there should be a breaking change in rules_nodejs with some automated tool for the migration.

[merceyz]

Just to note: you can use Yarn v2 with node_modules as a stepping stone, just run yarn config set nodeLinker node-modules.

Let facebook deal with that, they are staffed to roll yarn2 forward.

Facebook has nothing to do with Yarn https://yarnpkg.com/advanced/qa/#is-yarn-operated-by-facebook