Easier setup to test changes to the remix codebase

[LukasGerm]

If you are trying to contribute to the remix codebase, it seems to be quite hard to test out the changes you made to it. There should be an out of the box solution to test out changes made in the remix codebase, like an example project.

[rossipedia]

It seems as though the Remix team (and they can correct me if I'm wrong here) generally exercises the various Remix packages using unit and integration tests. Which is perfectly valid.

Some devs (myself included) like to poke and prod at things in a more free-form, uncontrolled fashion, where we want to create a project, and then configure it to use a local copy of the Remix repo, where we can make changes, build the Remix packages, and see those changes reflected in our sample project.

Remix is not very well set up for this style of development currently. Things I've tried while working on the @remix-run/dev package:

• npm link / yarn link from build/node_modules/@remix-run/dev and then npm link @remix-run/dev in my sample project - this caused some issues around module resolution in some packages that don't handle symlinks very well.
• ln -sf build/node_modules/@remix-run/dev $PROJECT/node_modules/@remix-run/dev - same issues as above.
• rsync build/node_modules/@remix-run/dev/ $PROJECT/node_modules/@remix-run/dev - this was difficult to keep in sync, and also breaks as soon as a dependency is changed in the Remix repo, since rsync (or cp or whatever) doesn't perform the actual npm install steps to keep the node_modules folder set up properly
• npm pack the individual packages I needed, mv them to the project folder, and then npm install $package.tgz - this is the method that I finally was able to get to work fairly painlessly, once I semi-automated it with the following script:

#!/bin/bash

SRC=~/src/gh/remix/
DST=~/src/remix/scratch

pushd $SRC 2>&1 > /dev/null

# create the packages in $SRC/build/node_modules
yarn && yarn run build

# the projects I want to build and install in my scratch project
PROJECTS="dev react server-runtime"

for d in $PROJECTS; do
  pushd $SRC/build/node_modules/@remix-run/$d 2>&1 > /dev/null
  
  # Pack it up into a tarball
  npm --quiet pack
  mv -f *.tgz $DST/

  pushd $DST/ 2>&1 > /dev/null

  # clear out old package
  npm --silent rm --no-save @remix-run/$d
  # install the freshly built package
  npm --silent i remix-run-$d*.tgz

  popd 2>&1 > /dev/null
  popd 2>&1 > /dev/null
done

This is obviously (at least, to me) not ideal. What I'd love is to just be able to do yarn watch in the Remix repo, make some changes, and then go and refresh my sandbox app and see those changes reflected immediately.

The conventional way would be to properly support npm link or yarn link, but another way I was thinking is have the Remix repo itself have a sort of create-sandbox command that would bootstrap a sample app that uses the local Remix repo's build output kinda auto-magically. Which, thinking about it some more, might be the shortest path to victory here.

There's also probably some work to be done around having remix dev in the sample project be able to watch for changing in the various @remix-run/* node modules folders, or otherwise making it aware that it's running in "use local Remix" mode.

Would love some input from the team on this one though! I absolutely love Remix and would love to see it become even easier to hack on by everybody :)

[LukasGerm]

What about some kind of yarn script which moves the build files into an example project in the remix codebase which rebuilds on filechanges?

[rossipedia]

That's kinda what I was going for with this part here:

another way I was thinking is have the Remix repo itself have a sort of create-sandbox command that would bootstrap a sample app that uses the local Remix repo's build output kinda auto-magically. Which, thinking about it some more, might be the shortest path to victory here

I think inverting the control like that, where Remix is the one creating and driving the sandbox app, probably makes the most sense.

[LukasGerm]

Ah, I'm sorry :D Yeah, we meant the same.