guybedford / chomp

'JS Make' - parallel task runner for the frontend ecosystem with a JS extension system.
https://chompbuild.com
Apache License 2.0
143 stars 7 forks source link

Dynamic deps #174

Open canadaduane opened 1 year ago

canadaduane commented 1 year ago

I have a javascript file that uses ES module imports. I would like to "run" the JS file whenever it changes, or any of its imported dependencies.

I can create a list of files easily, but outside of dynamically modifying the chompfile.toml file, I'm not sure how to get this dynamic list of deps into a [[task]]. Is this supported?

guybedford commented 1 year ago

Chomp doesn't trace JS dependencies or provide dependency tracing primitives. It would be great if it did something like that one day. The best bet for Chomp here is just to glob the files:

[[task]]
name = "run"
run = "node app.js"
deps = ["app.js", "src/**/*.js"]
zachsa commented 1 year ago

Is this similar in concept to hot module replacement? Seems if this exists then it would be possible to rebuild an application on save, but process only a few files each time.

canadaduane commented 1 year ago

I'm testing various aspects of writing a simple SSR server. Here's a trick that traces JS dependencies of ES modules without any tools other than node and grep/awk (on posix shell):

NODE_DEBUG=esm node public/index.html.js 2>&1 >/dev/null \
| grep "Storing file" \
| grep -v node_modules \
| awk 'NR>1 {sub(/file:\/\//, ""); print $4}'

Output:

/home/duane/Projects/credit/public/credit.js
/home/duane/Projects/credit/public/TodoList.js
/home/duane/Projects/credit/public/readFile.js

(index.html.js imports credit.js and TodoList.js; credit.js imports readFile.js; transitive dependencies work).

Is this similar in concept to hot module replacement?

That may be the direction, yes, although I'm not as concerned (yet) with hot reloading individual modules so much as knowing when to "build" a file that depends on other files.

Just poking around the edges of things :)

zachsa commented 1 year ago

I think I'm trying something similar - this site is a Node.js server that renders a react app server side.

My approach has been to use http imports for both the client and the node app, which allows for executing the react client on the node side before serving it.

react (tsx) + rollup on every save -> bundle +  jspm -> HTML page with import maps

Then on the Node side I generate an import map from the bundled client using JSPM. I have hijacked the node loader to sometimes load via http imports and sometimes from node modules depending on the import...

and things sort of work. Keen to discuss more! There are a couple aspects to my workflow that are not as easy as a webpack app would be and I am interesting in improving that

canadaduane commented 1 year ago

@zachsa That sounds like a pretty pragmatic way to do it--the node loader sounds particularly interesting.

I'm building an unorthodox web framework called credit that is in an early exploration stage. I'm trying to see what assumptions I can challenge--things like do I need an API if I use a CRDT algorithm? can I get away with a "no compile" workflow, but still get type checking? And finally (more relevant to this issue)--can I build only what is necessary for SSR, using Chomp? I may have a way forward, though, as it seems I was originally wrong about the assumption that I would need a build step for each dependency. I believe I can get away with a build step for just the root files. We'll see though.

zachsa commented 1 year ago

No idea what a CRDT algorithm is... but I'm keen to find out!

canadaduane commented 1 year ago

No idea what a CRDT algorithm is... but I'm keen to find out!

We're off-topic, so I'll be brief: check out https://lars.hupel.info/topics/crdt/01-intro/ and https://braid.org/antimatter