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

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.

Related to what I said before https://clojurians.slack.com/archives/C07UQ678E/p1687279795850579?thread_ts=1687252155.381169&channel=C07UQ678E&message_ts=1687279795.850579

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 :face_with_rolling_eyes:

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

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

I think the initial issue was that this didn’t match the indexing? https://github.com/mantinedev/mantine/blob/350051a3c40e51197bda27d818db013f9bdb90eb/src/mantine-core/package.json#L8-L12

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.

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

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

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.