Looking at the shadow-cljs source, it seems the answer is "no"

the array syntax is supported as it is widely used

but I believe it is not allowed for wildcards?

could also be broken. I don't think I have seen this in the wild

I am trying to work around an issue where I am using a javascript library that inconsistently uses fake paths, sometimes without .js extensions, other times with a .js extension. 😛

The interesting part is that every bundler I have tried handles it gracefully, but shadow doesn’t. Not shadow’s fault, though. There is next to zero documentation on how this exports key should work anyway

so the library INTERNALLY has lookups that rely on exports?

exports are usually only used for external lookups, i.e. requests from outside the package?

Ok, so there are two libraries at play. Library A has exports

{"./*": "./dist/src/*.js",
 "./*.js": "./dist/src/*.js"}

import { thing } from "@A/foo";

import { thing } from "@A/foo.js";

Library A has an invalid exports entry, based on the explanation youve provided me in an earlier thread. So I decided to experiment using the array syntax at the start of this thread, in attempt to “fix” the exports declared in library A’s package.json

At the moment, I decided to bite the bullet and manually refactor library B so that it consistently refers to files without extension. Now shadow can locate the files. (Just barely tested npx shadow-cljs compile app and it succeeded after refactoring about two dozen imports in library B)

maybe it is allowed that wildcard is other places, not just at the end

I never verified that assumption. Just seemed so from the webpack docs

if its a package on npm I can take a look and fix it

just haven't seen other examples of that in the wild so far

(I also didn't check a whole lot of package, basically only those users reported not working)

Unfortunately these libraries are company-internal libraries, but I can easily make a minimal project reproducing this issue I’ve faced. It’s just a matter of whether its worth supporting or not (probably not, since this is the first time I’ve ran into a JS library with huge inconsistencies in imports)

https://github.com/thheller/shadow-cljs/blob/561d4990d4ee8bbdb50fad537b5e9c4cd32f96c4/src/main/shadow/build/npm.clj#L95

I mean I wasn't sure when I wrote it and changing that to str/includes? is not a big deal

my take is that if there are package on npm using that it should be supported

if its company-internal relying-on-webpack-only that is a bit sketch 😛

well, I guess that answers this

https://nodejs.org/api/packages.html#subpath-patterns

the node docs even use that pattern

so I guess its supposed to be supported

oh these two libraries in question are some of the messiest typescript Ive ever seen

to make things play nicely with shadow I went and set up bundlers since they are doing all sorts of crazy things, like importing JSON files with an assert keyword that google-closure doesnt support

originally they simply ran tsc and the outputted JS didnt even work in Node.js or Chrome… let alone shadow and gcc. the tsconfigs have references and path aliases all over the place.

in any case, I managed to solve the problem I was facing — shadow’s existing functionality is sufficient for my needs

yeah people never pick up any discipline when webpack basically allow all sorts of random combinations 😛

I'm happy to fix it. its not a big deal

Sorry it took a while — here is a repro https://github.com/rome-user/shadow-exports-repro

https://github.com/thheller/shadow-cljs/commit/b3e22dada45389bff47ac3e788d97515b5eca2bb

the array thing will not work I believe

what did you test this with? I mean on the JS side that that actually works?

or did you just try that because

{"./*": "./dist/src/*.js",
 "./*.js": "./dist/src/*.js"}

"./*": ["./dist/src/*", "./dist/src/*.js"] I mean?

The array idea didn't work indeed. Even tsc got confused by the array exports

But tsc, tsup, rollup, vite, etc. all handle

{"./*": "./dist/src/*.js",
 "./*.js": "./dist/src/*.js"}

shadow will now too I think 😛

can you give it a quick test? Just paste this into your REPL and let shadow compile?

https://raw.githubusercontent.com/thheller/shadow-cljs/b3e22dada45389bff47ac3e788d97515b5eca2bb/src/main/shadow/build/npm.clj

sure, one moment

I mean I wrote a test, so should be fine but never hurts to test twice 😉

do i need to restart shadow if i forgot to npm install in a subproject?

no

I copy-pasted the code youve sent into my REPL, same error

package A had exports, but could not resolve ./foo.js
{:package #object[java.io.File 0x12f76ddf "/Users/****/Desktop/repro/packages/B/node_modules/A"], :require-from [:shadow.build.npm/resource "node_modules/B/src/two.js"], :rel-require "./foo.js"}
ExceptionInfo: package A had exports, but could not resolve ./foo.js
	shadow.build.npm/find-resource-in-package (NO_SOURCE_FILE:907)
	shadow.build.npm/find-resource-in-package (NO_SOURCE_FILE:888)
	shadow.build.npm/find-resource (NO_SOURCE_FILE:1027)
	shadow.build.npm/find-resource (NO_SOURCE_FILE:951)
	shadow.build.resolve/find-npm-resource (resolve.clj:123)
	shadow.build.resolve/find-npm-resource (resolve.clj:94)

and did you have the proper exports definition? not the array one?

https://github.com/rome-user/shadow-exports-repro/blob/master/packages/A/package.json#L5-L8

this is what’s being used

not the array one

this is part of the file structure of the project

src
└── repro
    └── demo.cljs
packages
├── A
│   ├── dist
│   │   └── foo.js
│   ├── package-lock.json
│   └── package.json
└── B
    ├── node_modules
    │   └── A -> ../../A
    ├── package-lock.json
    ├── package.json
    └── src
        ├── one.js
        └── two.js

works for me?

I don't know what this nested link business is about though?

ah thats just what npm does when “installing” local file as a package

Okay I found something interesting

For some reason shadow can build the project successfully now

I was triggering compilation with the Shadow CLJS web UI

When I clicked “Stop” in the middle of a compile then clicked “Compile” again, now the exports are being parsed properly

OK it looks like the issue is indeed fixed. watch, compile, and release work on my end now

did you maybe run a compile before the change? the package.json is cached, so maybe it just had the old one

(that wasn't parsed properly, i.e. without the change)

I did run compile before sending the new shadow.build.npm code to the REPL

yeah that won't work then

In any case, it works now. A sequence of “stop” and “compile” somehow evicted that cache

I can test it one more time without a compile, to be doubly sure

But as far as I can tell, the patch youve sent me works

Restarted shadow-cljs in REPL, this time making sure to not compile before patching shadow.build.npm. It indeed works

let me see if I can squeeze in another unrelated change

I'll make a proper release in a bit regardless

2.28.4 is out

first check: does /Users/danielneal/development/qrart/node_modules/swiper/package.json exist?

2nd check: which shadow-cljs version do you use?

Yep the node_modules/package.json exists ➕

thheller/shadow-cljs {:mvn/version “2.19.1”} is my shadow-cljs version

that is too old. proper support for exports was added way later and that package uses exports

ah great, I’ll update

Sorry for the noise!

Discussion at https://clojurians.slack.com/archives/C073DKH9P/p1713991886010719

well. Is the watch for this build running? Is it?

jack-in is an extremely complex setup and I do not know if you have configured that correctly, nor would I know how that looks

normally you'd have a npx shadow-cljs watch app or whatever task running

with jack-in that is handled elsewhere and I cannot help you debug that

I do not know if the watch for this build is running. I did not do that manually the first time, when it worked. That was somehow spawned by cider-jack-in-cljs. Whatever it did the first time did not happen the second time. Perhaps someone more familiar with cider-jack-in-cljs can add some insight.

you can open http://localhost:9630 for the shadow-cljs UI

it'll show if the watch is running or not

for cider help ask in #C0617A8PQ

or you know ... skip the entire jack-in nonsense

run shadow-cljs as the docs suggest, i.e. npx shadow-cljs watch app manually

and then cider-connect instead

but again .. can't really help you with that either. I do not use emacs

The docs clearly indicate that cider-jack-in-cljs is supported and valid: https://shadow-cljs.github.io/docs/UsersGuide.html#cider

I cannot verify that. I assume it works but I couldn't tell you 1bit of how

That’s OK. Thanks for the info. Perhaps someone else will be more familiar with the jack-in command

It works now. I deleted the .dir-locals.el file (which the same above linked docs suggest setting up in section 15.2.2 as a means of storing defaults). I killed the existing session, and restarted with cider-jack-in-cljs, and it just worked as expected after that. I have no information beyond that, but I leave this here for future searchers who might encounter this issue.