Pain Point: Writing a library and an application in parallel is not ergonomic

[kernalphage]

Related issues

Workspaces / Shared projects

User Story

Let's say you're developing PersonalApplication and you start finding duplicate patterns/classes/functions that should be put in a separate library. Here are some issues you might encounter

• Separating out the dependencies is undecidable
• Iterating on the library is multiple steps, usually some flavor of "build", "publish", then import
• Versioning & local changes can get out of sync or in an unknown state fairly quickly
• It's easy to lose the meaning of a commit (this library patch == Y application feature)

There's a range of contexts here that decide whether the library or application should be in control control of which change to use:

• Are you a library developer working on a test library?
• A lib dev working on a bug in a previous version, w/an external application
• A developer making a personal library? (my personal pain point)
• A developer wanting to make a patch to an external library?
• A company that has to manage multiple versions and patches of the same library?

Prior art:

simlinks - simplest, but doesn't play nicely with version control
npm link and yarn link: basically a symlink with extra steps, currently buggy.
yalc?
Git-submodule - Works, but there's no connection between commit and npm project version

(I'm using commit/patch/local change interchangeably, hopefully that makes sense!)