let JS deal with JS and don't try to understand it, is my mantra ;)

that doesn't help trying to implement this mess unfortunately 😛

don't implement it, but let JS tools complain about themselves, just compile to JS and then let those tools deal with the mess

unfortunately more and more packages are starting to use "exports". so for shadow-cljs to bundle them I kinda have to.

not yet at the point where I'm giving up and discontinuing the JS support in shadow-cljs, although its close 😉

btw, off topic, but: I just tried to upgrade clerk from shadow 2.23.1 to the newest, it uses target esm, but viewing a notebook failed, not sure if it rings a bell, but I'll try to make a proper repro

the actual error would help. "notebook failed" doesn't mean anything to me. I changed how esm code is loaded because of problems in node, totally possible I accidentally broke something

yeah, I know :)

will look into it now

perhaps it's fixed in .5 which wasn't there yesterday, I'll try it

so I'm getting this with .4 in watch mode: I'll now try .5

no dice with .4 either. I'll try to backtrack and continue in #C6N245JGG

seems to me like those files should exist?

dunno. with .3 I can get it working

can't really tell what those paths are supposed to be. they are weirdly truncated, whats the actual url?

in clerk development: http://localhost:7777/notebooks/dice.clj

no I mean the 404 urls, like what is the full url of the first react_production.min.js?

something like this:

ah nvm, I can reproduce. its not accounting for eliminated JS deps. ie. this is a dev build, it shouldn't try to load the min file

nice

try 2.23.6

Failed to inspect file
  /Users/borkdude/dev/clerk/node_modules/tslib

FileNotFoundException: /Users/borkdude/dev/clerk/node_modules/tslib (Is a directory)
	java.io.FileInputStream.open0 (FileInputStream.java:-2)
	java.io.FileInputStream.open (FileInputStream.java:219)
	java.io.FileInputStream.<init> (FileInputStream.java:158)
	 (io.clj:231)
	 (io.clj:231)
	 (io.clj:71)
	 (io.clj:167)
	 (io.clj:167)
	 (io.clj:71)

I can paste more of the stack trace if you want

yes, without that I cannot tell why it failed

if its exports related you can set :js-options {:ignore-exports true}. that'll make it go back to old behavior

I tested exports stuff on a bunch of packages but far from all of them. absolutely expected to fail in some cases

here you go: https://gist.github.com/borkdude/14e8b6b996369249224e01bb60a56197

absolutely gotta love this mess https://unpkg.com/[email protected]/package.json

"./": "./"

don't shoot the messenger :)

try 2.23.7 or set :js-options {:ignore-exports true} if you want to avoid further issues

I'll do some more testing myself later I guess

next error: https://gist.github.com/borkdude/880c918ca22f3ac94a74d592b31b5863

doh, try 2.23.8

next error: https://gist.github.com/borkdude/b247637e497e8e52dcdce3b2f62ec94f

> This file is being treated as an ES module because it has a '.js' file extension and '/Users/borkdude/dev/clerk/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.

ESM is nothing but trouble 😛

I guess due to exports its now using ESM code where it previously wasn't, and that still runs through babel

can you do a quick test and cd .shadow-cljs/babel-worker/; npm init -y and run again? guess that won't do anything though. guess I'll rename it to .cjs

wonder why this didn't happen before

That seems to cause the build to succeed, but I still get this error at runtime:

Group.mjs:1 Uncaught TypeError: (0 , React.forwardRef) is not a function
    at shadow$provide.module$node_modules$framer_motion$dist$es$components$Reorder$Group_mjs (Group.mjs:1:132)
    at shadow.js.jsRequire (js.js:74:17)
    at shadow$provide.module$node_modules$framer_motion$dist$es$components$Reorder$index_mjs (index.mjs:1:132)
    at shadow.js.jsRequire (js.js:74:17)
    at shadow$provide.module$node_modules$framer_motion$dist$es$index_mjs (index.mjs:1:113)
    at shadow.js.jsRequire (js.js:74:17)
    at shadow.js.require (js.js:112:1)

in the browser

I guess all this confirms that suspicion https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/npm.clj#L971-L973

still can't reliably mix commonjs and esm code

can you try :js-options {:export-conditions ["require" "browser" "default"]} ?

Will do. This is the total config:

{:deps {:aliases [:sci]}
 :dev-http {7778 {:roots ["public" "classpath:public"]}}
 :nrepl false
 :builds {:viewer {:target :esm
                   :runtime :browser ;; `:custom` needed when developing ssr, will see WebSocket errors without it
                   :output-dir "public/js"
                   :release {:output-dir "build/"}
                   :compiler-options {:source-map true}
                   :dev {:modules {:viewer {:entries [devtools]}}}
                   :modules {:viewer {:entries [nextjournal.clerk.sci-env
                                                nextjournal.clerk.trim-image]}}
                   :js-options {:output-feature-set :es8
                                :export-conditions ["require" "browser" "default"]}
                   :build-hooks [(shadow.cljs.build-report/hook
                                  {:output-to "report.html" :print-table true})]}}}

it worked

good to know. thanks.

> still can’t reliably mix commonjs and esm code webpack does this though doesn’t it? ie. it supports bundling libs that can be a mix of esm & cjs modules?

> unfortunately more and more packages are starting to use “exports”. so for shadow-cljs to bundle them I kinda have to. Indeed this has been coming up often with me lately. I’ve just been overwriting webpack resolve.alias to ignore package exports in several cases - and I just manually point it at where to look in the lib distribution. This is also brittle to if they move things around later. ☠️