I tried this, but the builtin reagent doesn’t seem to be satisfied if I require react myself this way before loading reagent itself

I mean, it seems it still wants to load react relative to nbb itself instead of relative to the script

yeah thats what I mean. if you require it from the ns it'll be relative to the source itself

so the global install. if you instead require it dynamically via createRequire it should be fine

IIRC there is also an enviroment variable NODE_PATH or NODE_INLUDE_PATH or something like that

maybe you can find a way with that. needs to be set before starting node though so might be tricky

If you require it from the ns… doesn’t Reagent itself require react from the ns? How can I make that use createRequire?

oh right. forgot that you are not in control of that require

did you experiment with a simple node script that creates a secondary process actually running nbb? that way you can control the NODE_PATH env or whatever. assuming thats actually still a thing

I didn’t do that yet, but this may be the most flexible solution, if it works. I guess it could also just be a bash script

So I guess I'll have to rename my bin to nbb-runner and expose an additional nbb script which is bash on linux/macOS and .cmd or so on Windows with:

#!/usr/bin/env bash

NODE_PATH=$NODE_PATH:$PWD/node_modules nbb-runner $@

or actually, not PWD, but the node_modules relative to the script rather

pretty sure you must not specify the node_modules

I did have to do that

default node resolve rules will append that anyways?

I've made some notes here: https://github.com/borkdude/nbb/issues/25

It seems you can "hack" using module.constructor._initPaths which, if this isn't _too_ hacky, is my preferred solution as this makes deploying stuff much easier

seems reasonable

do you mean the module.constructor hack?

yeah

yeah, might work. I tried to incorporate this into nbb.main but it complained about module not being available in ESM module scope

pretty sure thats the "module" require?

I just wrote (js/module.constructor._initPaths) etc

I didn't require "module" explicitly (but I think I have done this in the past and that failed as well)

require('module').Module._initPaths()

you mean via the createRequire?

there I think I need import.meta.url to pass it to the createRequire

and google closure won't allow this in advanced compilation :/

yo do not need that

you can require that normally in your code

but require doesn't work in this ESM module

I can't write (js/require ...), that is not allowed

(:require ["module" :as m]) (m/_initPaths)

let me try that

the .Module seems to be a circular reference back to itself so you can skip that

of course you need to add the path first

just calling init alone won't do anything

I understand

$ node out/nbb_main.js script.cljs
file:///Users/borkdude/git/nbb/out/cljs-runtime/nbb.core.js:3
import$module._initPaths();
^

ReferenceError: import$module is not defined

this might be because it's not a CommonJS module?

I've found that function yes

it exists in the Node REPL etc

wait WHERE did you require that

in nbb.main

in the script.cljs or in nbb code?

and this was a regular compile not some REPL hot-reload or so?

should be fine? don't see a reason why it wouldn't be

I've tried regular compile, advanced, both same error

ah hehehe

https://github.com/thheller/shadow-cljs/blob/36b30359447391ac6fc360178ad5cd392aa1e1b2/src/main/shadow/build/js_support.clj#L134

probably running into that one 😛

shim on you

hmm no wait that should be fine

import$module is the correct name. dunno why its not defined

I've seen errors like "module is not defined in import / ESM scope" before somewhere, can't recall exactly when

FWIW, pushed it here: https://github.com/borkdude/nbb/tree/init-paths

this is not that. you are importing it. so it is defined.

yeah ok. I could try JS interop directly after import

this is pointless

(when require
      (set! (.-require goog/global) require))

there is no global require and there shouldn't be

it is not pointless since this makes (js/require "foo") work in the interpreted code

I thought thats what https://github.com/borkdude/nbb/blob/init-paths/src/nbb/main.cljs#L20 is for

ah gotcha. when using direct JS interop:

$ node out/nbb_main.js script.cljs
file:///Users/borkdude/git/nbb/out/cljs-runtime/nbb.core.js:3
module["constructor"]._initPaths();
^

ReferenceError: module is not defined in ES module scope

@U05224H0W that :require require is passed to the namespace evaluation logic, but users can also do interop on the global object directly

get rid of the constructor thats pointless

and yes module without a require or import doesn't exist. that is expected.

thats why you import it

$ node out/nbb_main.js script.cljs
file:///Users/borkdude/git/nbb/out/cljs-runtime/nbb.core.js:3
module._initPaths();
^

ReferenceError: module is not defined in ES module scope

you need to differentiate about what module you are talking about

the implicit module you get in commonjs code is different from the one you get via the "module" module

so how you modify that is different depending on how you work with it

so the implicit module you'd go via .constructor or .Module the others do not

don't have time now but maybe I can figure this out over the weekend

there have been a bunch of changes in the closure compiler regarding this as well so maybe the whole shadow.esm/dynamic-import stuff isn't necessary anymore

cool

This is the entire output btw:

$ node out/nbb_main.js script.cljs
file:///Users/borkdude/git/nbb/out/cljs-runtime/nbb.core.js:3
cljs.core.prn.cljs$core$IFn$_invoke$arity$variadic(cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2([module], 0));
                                                                                                     ^

ReferenceError: module is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and '/Users/borkdude/git/nbb/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at file:///Users/borkdude/git/nbb/out/cljs-runtime/nbb.core.js:3:102
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
    at async Object.loadESM (node:internal/process/esm_loader:68:5)
    at async handleMainPromise (node:internal/modules/run_main:63:12)

(this is from (prn js/module))

which is not right as I should be using m obviously

yes, js/module is not supposed to exist

This gives:

(prn m)
(prn (._initPaths m))

#object[Object]
nil

so it works fine?

no, the nil shows that _initPaths is not there

oops typo

hmm yeah its calling the function and that returns nil? seems fine?

indeed, the function seems to exist...

ok, I'm going to try some stuff now that this seems ok

seems to work :)

👍

crap, I think I was too early. it probably picked up a "react" from an earlier install in node_modules. it seems npm remove -g nbb doesn't clear that

it doesn't seem to work, alas

perhaps the dynamic import doesn't pick up on the NODE_PATH stuff

or the way how reagent requires react

I thought for the interpreted code you are setting up the require via createRequire?

I mean just don't use import in any interpreted code?

ok, to tease things apart a bit: my nbb.core namespace is compiled as an ESM module my nbb.reagent namespace is compiled as an ESM module why? because code splitting only works with ESM modules currently nbb.core loads nbb.reagent on demand. the only way this works (I think) is via dynamic import (ESM modules) Then nbb.reagent loads a pre-compiled version of reagent. This doesn't run through the interpreter, it is pre-compiled. So that's just normal CLJS requires happening in reagent.

ah right. hmm yeah no idea about the ESM part

The way it is solved currently is to just have an optional dependency on react

so when people load reagent, reagent loads the react dependency from nbb

https://github.com/nodejs/modules/issues/534#issuecomment-661937336

$ npx shadow-cljs compile test
shadow-cljs - config: /Users/borkdude/git/nbb/shadow-cljs.edn
shadow-cljs - starting via "clojure"
[:test] Compiling ...
========= Running Tests =======================
file:///Users/borkdude/git/nbb/target/test/test.js:5
var SHADOW_IMPORT_PATH = __dirname + '/../../.shadow-cljs/builds/test/dev/out/cljs-runtime';
                         ^

ReferenceError: __dirname is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and '/Users/borkdude/git/nbb/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at file:///Users/borkdude/git/nbb/target/test/test.js:5:26
    at file:///Users/borkdude/git/nbb/target/test/test.js:1571:3
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
    at async Object.loadESM (node:internal/process/esm_loader:68:5)
    at async handleMainPromise (node:internal/modules/run_main:63:12)

That's what I was fearing

I always recommend using a separate output directory per build. don't mix them

so you output the esm stuff to packages/nbb with its own package.json in that dir

and tests whereever but not in that dir

that way you also never have to worry about including files in the published package that shouldn't be there (eg. cljs sources)

or create a test-out with its own package.json. really up to you

or just output-to to a .cjs file like the error suggests. many possible solutions

but isn't the point of the tests that they can load my app code?

trying .cjs

the compiled version no, your namespaces sure

is it possible to add a src dir test only for the test build?

I am using :deps true

something like :aliases [:test] on the level of the build for example which would pull in :extra-paths ["test"]

https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

just put it always on. it doesn't affect your builds in any way.

I'm using :deps true but I'll use :deps {:aliases [:test]} then