hmm in what context does that happen? doesn't look like a shadow-cljs error? and its a perfectly valid import?

It's in bun — maybe that is the issue.

its also not an import call? call being import()

I'd assume that bun understands ESM?

https://bun.sh/blog/bun-v1.0.14#errors-for-unsupported-esm-commonjs-features

dunno if thats relevant but it shows up as first hit on google 😛

could be that its attempting to load the file as commonjs

Weirdly when I just import the file in a standalone JS file and run it with bun its all fine

in node you need to set type: "module" in package.json

dunno if there is an equiv for bun

I would have assumed that bun would fix some of the node nonsense

but guess not 😛

Hm now I tried logging whatever cljs_env.js exports and got this error

1 | (function (entry, fetcher)
    ^
SyntaxError: Missing 'default' export in module 'server-out/cljs-runtime/cljs_env.js'.

why would it need a default export?

also dunno what that line is, its not shadow-cljs code?

no, it's just bun file.js

import env from "./server-out/cljs-runtime/cljs_env.js";

console.log(env)

ah, yeah it doesn't have a default export, so that won't work

it doesn't export anything at all

Ah ok

in esm development builds everything is running using globalThis

so exports are only used for release builds and the defined :modules in the build config

$ bun js/main.js
Module {
  Box: {
    $$typeof: Symbol(react.forward_ref),
    render: [Function: Box],
    displayName: [Getter/Setter],
    defaultProps: {
      flexWrap: "nowrap",
      flexDirection: "row",
      flexGrow: 0,
      flexShrink: 1,
    },
  },
  Newline: [Function: Newline],
  Spacer: [Function: Spacer],
  Static: [Function: Static],
  Text: [Function: Text],
  Transform: [Function: Transform],
  measureElement: [Function: measureElement],
  render: [Function: render],
  useApp: [Function: useApp],
  useFocus: [Function: useFocus],
  useFocusManager: [Function: useFocusManager],
  useInput: [Function: useInput],
  useStderr: [Function: useStderr],
  useStdin: [Function: useStdin],
  useStdout: [Function: useStdout],
}

just tested a dummy build, runs fine in bun

Can you require transit?

I haven't had an issue until that, it all worked totally fine

[com.cognitect/transit-cljs "0.8.280"]
[cognitect.transit :as t]

hmm indeed

just requiring that causes the problem

Yeah, same here

ah .. you didn't show the full error

1 | import "./cljs_env.js";
    ^
SyntaxError: Unexpected string literal "./cljs_env.js". import call expects one or two arguments.
      at <parse> (/mnt/c/Users/thheller/code/shadow-cljs/out/esm-node/js/cljs-runtime/com.cognitect.transit.js:1:1)

I suspect it gets confused by this

if (TRANSIT_NODE_TARGET) {
    module.exports = {reader:transit.reader, writer:transit.writer, makeBuilder:transit.makeBuilder, makeWriteHandler:transit.makeWriteHandler, date:types.date, integer:types.intValue, isInteger:types.isInteger, uuid:types.uuid, isUUID:types.isUUID, bigInt:types.bigInteger, isBigInt:types.isBigInteger, bigDec:types.bigDecimalValue, isBigDec:types.isBigDecimal, keyword:types.keyword, isKeyword:types.isKeyword, symbol:types.symbol, isSymbol:types.isSymbol, binary:types.binary, isBinary:types.isBinary, 
    uri:types.uri, isURI:types.isURI, map:types.map, isMap:types.isMap, set:types.set, isSet:types.isSet, list:types.list, isList:types.isList, quoted:types.quoted, isQuoted:types.isQuoted, tagged:types.taggedValue, isTaggedValue:types.isTaggedValue, link:types.link, isLink:types.isLink, hash:eq.hashCode, hashArrayLike:eq.hashArrayLike, hashMapLike:eq.hashMapLike, equals:eq.equals, extendToEQ:eq.extendToEQ, mapToObject:transit.mapToObject, objectToMap:transit.objectToMap, decoder:decoder.decoder, 
    UUIDfromString:types.UUIDfromString, randomUUID:util.randomUUID, stringableKeys:writer.stringableKeys, readCache:caching.readCache, writeCache:caching.writeCache};
  }

Ahh, just realizing that now, sorry!

yep, if I remove that it works fine

I guess it has some detection for module.exports and doesn't do the partial if (TRANSIT_NODE_TARGET) evaluation

blame transit since that should never be in that file ... but it has always been in there ...

I guess you could make a copy of that file and just put it on your classpath?

https://github.com/cognitect/transit-js/blob/master/src/com/cognitect/transit.js

just remove the two ifs at the bottom

Trying but getting

--- com/cognitect/transit.js:9
A file cannot be both an ES6 module and a script file that contains at least one goog.provide.

in what context is this? WHEN do you get this?

[:server] Compiling ...
[:server] Build failure:
Closure compilation failed with 1 errors
--- com/cognitect/transit.js:9
A file cannot be both an ES6 module and a script file that contains at least one goog.provide.

Sorry, I just made the same mistake again. This appears in the shadow build process

hmm weird. I'm not sure why this works when its in a jar but not a file?

could be a shadow-cljs getting confused since it doesn't have a goog.provide or goog.module call

dunno why this weird format was chosen

ah! I think the mere presence of module.exports makes the closure compiler think this is commonjs

so it doesn't use the default ESM

but if you remove the module.exports thats gone and now it gets confused

gotta love JS ...

I don't have a simple solution. easiest is probably forking transit and rewriting it a use goog.module or actual closure-js. dunno why this goog.scope stuff was used

but also not sure why this works for all the other files but not the transit.js. could totally be shadow-cljs just being confused, but I'm not sure why

Hm bummer... the road to ESM will be bumpy 😄

try with --verbose to see where actual time is spent. but my guess is that all leftover time is spent in optimizations

second pass uses cache, so it skips recompiling most of the files

but optimizations are not incremental, so it cannot really be sped up

4437 files is kinda nuts 😛

Yeah 🙂

otherwise probably worth checking the build report https://shadow-cljs.github.io/docs/UsersGuide.html#build-report

and look for stuff to maybe make the build smaller

Just checked --verbose, you’re right, Closure - Optimizing ... (75233 ms) which is 80%. Pretty much no cljs file was compiled except a few with macros inserting contents from non-cljs files. I guess not much we can do to speed up the optimising step?

> Pretty much no cljs file was compiled except a few with macros inserting contents from non-cljs files.

what kind of content?

We have a custom solution generating clojure constants from css styles

and are those inserted as EDN? deeply nested EDN data optimizes very poorly and slowly

as in a macro ending up as (def styles {:huge {:nested "map"} ...})

I'd recommend starting with the build report

files that remain large after optmization often also mean they took the most time to optimize

unfortunately there are no more detailed stats available, so kinda hard to guess but I helped people before that inlined some rather big EDN data and after my recommendation to remove and fetch at runtime reduced build time by like 90%

not that you should ever even consider inlining anything that large (100kb+) to begin with

> and are those inserted as EDN? deeply nested EDN data optimizes very poorly and slowly I’ll check! Thanks @U05224H0W

which lodash version do you use? its one of those packages that kinda constantly changes how its organized

if there is a c:\clj\shadow-browser-exp\node_modules\lodash\flow.js it should be ok

maybe you just don't have lodash installed at all and only lodash.flow, which is a separate package

I'm using "lodash.flow": "^3.5.0", in my test app (original issue was seen in a dep package)

well if you don't have the lodash package installed it obviously can't be found

lodash/flow means its a file in the lodash package

`ls -al node_modules/lodash.flow/ total 34 drwxrwxrwx 1 chaos None 0 2024-03-28 15:53 . drwxrwxrwx 1 chaos None 20480 2024-03-28 15:55 .. -rw-rw-rw- 1 chaos None 1951 2024-03-06 08:24 LICENSE -rw-rw-rw- 1 chaos None 439 2024-03-06 08:24 README.md -rw-rw-rw- 1 chaos None 11640 2024-03-06 08:24 index.js -rw-rw-rw- 1 chaos None 737 2024-03-06 08:24 package.json

lodash.flow is an entirely separate independent package with no relation

npm install lodash if you want to use lodash/flow

I see, let me have another look at the dep package

indeed, the dep package, although it only declares lodash.flow as a dependency, it does eventually pull in the lodash pkg. Thanks for you help, I'll pick it up from here