Local development workflows / local package linking

[guybedford]

When working with local packages, there's no workflow to selectively apply the node_modules provider just for packages in development.

Perhaps if we had a way to provide a selection like this, that might work well with a standard npm dev workflow. Alternatively sepecifying the full path to the development overrides.

Altermatively, perhaps the recommended way to do this should just be with resolutions properly supporting file:../local-pkg style local resolutions?

This was brought up by @pvh that further polishing of these workflows is needed.

[pvh]

Here's the awkward solution that I found. Obviously this doesn't really scale to a lot of packages at once, but this was about testing a new implementation without wanting to cut a release before validating it in a production app.

First, I marked the packages in question as being provided by nodemodules. In my vite.config.ts we have a generateImportMapPlugin which uses the generator to build up the import map. I modified it thus:

    const generator = new Generator({
       env: ["browser", "module"],
       providers: {
        "@automerge/automerge-repo": "nodemodules",
        "@automerge/automerge-repo-react-hooks": "nodemodules",
     },
   });

Then, I had to actually copy the files into place. This is the part that makes this setup extra awkward. I added this to my build steps to copy the package I was working on into place.

"build:repo": "mkdir -p ./dist/node_modules/@automerge/automerge-repo && cp -R ../../automerge-repo/packages/automerge-repo/* ./dist/node_modules/@automerge/automerge-repo",

I think this was particularly awkward because we had a mix of nodemodules and JSPM.io provided packages but it did work and once I settled on this approach I didn't have to manually enumerate dependencies of the two packages above (as I did when I manually resolved them to a path!)

I'm not sure what the best approach would be. Possibly I should move the whole project to using nodemodules for consistency and to avoid creating a dependency on a separate remote service (the JPSM.io package CDN). I haven't thought too deeply about it yet.

Perhaps there would be an approach that would pair with a CLI command to copy the necessary files into the expected place, or I could modify the plugin accordingly? Maybe a dev server (I don't love that, feels too complicated).

Anyway, this worked! It might be worth at least documenting the approach somewhere.

[guybedford]

Does this same workflow work without the copy step if you symlink the dist/node_modules/@automerge/automerge-repo folder to ../../automerge-repo/packages/automerge-repo?

This would effectively be the traditional npm link workflow in that case, which is what npm's local development story was supposed to be like as well.

Another alternative might be through the package.json dependencies:

{
  "dependencies": {
    "@automerge/automerge-repo-react-hooks": "file:../automerge-repo/packages/react-hooks",
    "@automerge/automerge-repo": "file:../automerge-repo/packages/automerge-repo"
  }
}

where JSPM will use these resolutions instead of the CDN resolutions, and therefore should avoid the need for the nodemodules provider override.

One issue with the above workflow though is it may not correctly dedupe other importers - perhaps having better local dependency override systems could help with that.