cljs-dev 2023-09-20

But what is the problem? Is the exports actually wrong?

Or we mishandle?

Npm exports won't contain the npm dependency. So mishandle.

that I do not follow?

exports is supposed to be for exporting the entry point

It does, but providing a map seems to let them distinguish between es6 import and cjs require.

🤯 1

but what is the actual problem I guess? that we should have a knob to choose one or the other?

I improved the exports handling to at least make it easier to fix up stuff like this and easily add test cases

No knob needed I think. Just need to recurse in and pick one using the existing strategy.

oh I see the problem is we just assume there’s one entrypoint

Yeah. There's a to-do to handle ".", but it's not implemented šŸ˜…

ok I will take a look this week, this seems easy

ā¤ļø 1

Yeah I think it is. There's a couple of bits of low hanging fruit here.

what else is needed?

The main need is handling ".". But it would also be easy to add support here for falling back if the first file can't be handled. https://clojurians.slack.com/archives/C07UQ678E/p1695239919424459?thread_ts=1695236507.809009&cid=C07UQ678E

hrm I don’t know what ā€œfirst fileā€ cannot be handled means?

in what situations could that occur? Sorry this stuff is not that easy to understand w/o being crystal clear

Can't be handled in this case means that the file extension was .mjs, and the package resolution code I linked can't handle that. In that case it would be useful to try the next thing in the list and see if that can be handled.

basically I don’t want to collapse two issues into one, otherwise I’m going to get confused what we’re talking about here.

Yeah, that's fair. Handling . Is the main thing

k got it - two distinct issues - both seem simple

šŸŽŠ 1

what is this esm.js case? like what is the dependency, the unit tests install them to do the check.

@mantine/mantine-core for the first case, and react-hook-form-mantine for the second.

So is this resolved?

Not exactly, no. I have a workaround, but it only happens to work because I'm not using many npm dependencies right now.

It's definitely plausible my workaround will bite me later. It's also quite unfriendly to figure out right now.

I'm not against adding another thing to match if that isn't going to cause problems

šŸ‘ 1

awsome thanks

It does seem to be indexed as @mantine/core, so I'm a bit confused about why I'm getting an error, actually. user=> (filter #(contains? (set (:provides %)) "@mantine/core") (cljs.closure/index-node-modules-dir nil)) ({:file "/home/overfl0w/workshop/app2/node_modules/@mantine/core/esm/index.js", :module-type :es6, :provides ["@mantine/core/esm/index.js" "@mantine/core/esm/index" "@mantine/core" "@mantine/core/esm"]})

I get

No such namespace: @mantine/core, could not locate _CIRCA_mantine_SLASH_core.cljs, _CIRCA_mantine_SLASH_core.cljc, or JavaScript source providing "@mantine/core" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file src/.../foo.cljs

OK, so switching to :package-json-resolution :webpack solves my problem with mantine... but introduces a problem with another library which has "module": "dist/index.esm.mjs" . That isn't detected by https://github.com/clojure/clojurescript/blob/0da9884836e9f8ba190f3b789adcb6b9b85a669c/src/main/clojure/cljs/foreign/node.clj#L125-L128 so ends up getting ignored, rather than trying the next entry. patch welcome?

It’s not a perfect solution but if cljs doesn’t export indexing the way you need, you could figure out what CLJS does find and use that in your :require If you are using newer bundler like webpack v5+, it’ll fail due to it violating the package exports. You can workaround that with an explicit resolve.alias entry in the config.

So you’ll end up with a package structure dependent :require to get CLJS to recognize it.

I was violating the webpack package exports... but I didn't know about the resolve.alias, that's handy! I ended up setting a custom :package-json-resolution ["browser" "main" "module"] which happens to work for my dependencies šŸ™„

I’ve never messed with the new resolution options there. But good! I’ve used resolve.alias quite a bit for webpack. But it’s nice if you don’t need to