action.cljs. It uses
vercel/ncc to package the JS, including nbb, into one file,
dist/index.mjs which is then used by the Github runner. This packaged JS only needs to change when your dependencies change. The actual logic in
action.cljs is packaged separately and doesn’t need recompilation since nbb uses SCI for running the code. I wouldn’t say this approach is superior to using CLJS or Shadow directly, but I think writing this kind of code can be seen as scripting as well and falls within the use case that nbb is designed for.
by the way, I see “custom version of Node.js” in docs. what does it mean? Another Node.js binary? or official Node.js but with some configurations?
I don’t see those exact words in the docs, but I suppose you mean the workaround in
For local development you can just run
node index.mjs but in the Github runner we need to invoke
run.mjs and how this works is:
The runner, configured via
"node12" starts with an old Node.js v12 which doesn’t support ES modules yet. But by now the runners have Node 14 installed as well, which is available on the path by default. So
run.mjs forks the process by launching the system-wide Node.js in the runner.
This should not matter to the developer, it’s just a workaround for the Github environment.
Thanks. So literally, it requires the feature of loading ES modules.
That quote was from docs of nbb https://github.com/borkdude/nbb/#goals-and-features .
I was referring to lumo which pulls in a custom Node version. Nbb just runs on the Node you already have installed.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.