Alex Eagle

There's a recent proposal to make pnpm semantics in npm itself. Given limited time of maintainers here I think we have to focus exclusively on the "canonical" tooling which is...

https://github.com/npm/rfcs/pull/436 Is the proposal that I think we should align with

Hey @arcanis thanks for stopping by! I agree PnP support is the real request here. We are kinda novice at the details of what that means for the package manager...

#3071 tracked supporting yarn 2+, let's continue using this one for supporting PnP. The former is solved at HEAD but the latter isn't, so I reopened this.

This repo no longer supports any package managers. aspect-build/rules_js supports pnpm, and others are free to make rulesets specific to Yarn or npm (or whatever new flavor-of-the-month is invented next)

I've been thinking/discussing this. I think we should build a clean-room implementation of ts_library that brings in only the minimal bits - just run TypeScript with its composite projects feature...

Discussed with @rictic today, still feels promising. We'd want it for google-internal too.

I bet there is a lot of memory wasted because the transitive closure of .d.ts probably does include lots of overlap (lib.dom.d.ts for example) But I think it's a good...

I went to read up on https://www.typescriptlang.org/docs/handbook/project-references.html TypeScript handles it by incrementally rebuilding the dependency graph. That sounds like it's probably Bazel's job and we don't want to pass the...

Adding multiplex support in `@bazel/worker` seems like the right first prerequisite step. It's a little tied up with google-internal right now. The `@bazel/worker` package implementation is just to copy some...