what is the actual problem you are seeing? do you get an error? unexpected output?

I see the following: #schema.utils.ErrorContainer{:error {:policies missing-required-key, "policies" disallowed-key}} Schema is (s/defschema bb {:policies #{s/Str}}) and I'm using a coercer which has worked just fine under the jvm to do the right thing. Was wondering if there's a cljs trick I'm missing.

I've tried js/import.meta, but that reports Execution error (ReferenceError) at (<cljs repl>:1). import$ is not defined.

Which may be because I'm trying it from the repl and I think it only works inside a module, but this will be in a ES module.

So this library will be usable only from JS?

No, it's a cljc module, but the jvm side is easy because we have a classpath.

And how will you consume the assets within CLJS?

It won't work while hosted in the browser, but in node the plan is to use fs/readFileSync

If the trouble is only with import being renamed into import$, then you can try using js* - not documented, IIRC, but will emit its string argument as is. I.e. (js* "import.meta.url") will become import.meta.url in the compiled JS.

!!! I think that will work. I'm now getting a proper error: Cannot use 'import.meta' outside a module, but I'm pretty sure that's because I'm working from the repl.

it'll also blow up in release builds processed by the closure compiler

import.meta only works in ESM code

doesn't make sense to use in a node setting anyways

the shadow-cljs command reads a file shipped with the npm package like this

https://github.com/thheller/shadow-cljs/blob/bf38b2c4c68c2dbd634948155ca0572cefcf739b/src/main/shadow/cljs/npm/cli.cljs#L118

so, basically just a fs/readFileSync

js/__dirname is the special binding to get the dir of the current file (meaning the produced JS file, not the CLJS file)

https://unpkg.com/browse/[email protected]/cli/ this is the contents of the npm package. dist.js is the compiled CLJS output

The problem is when this library is used in another application and is living in node_modules/path/to/my/package/ then I need to be able access the /assets folder of the library even though the relative directory has changed.

I was looking at this thread to come up with the new URL("filename", import.meta.url) solution.

https://github.com/webpack/webpack/issues/7353

ah, webpack. yeah thats a different story

normally just require works

assuming webpack that is, won't work in node or the REPL

I'm not using webpack, that's just the only place where I could find a discussion on how to do it.

yes, because this is a webpack feature

there is no native support in the browser for this

no matter what. you need something that puts the files out of the npm package into a web accessible location

But I'm not dealing with the browser - as long as Node has support for this ES syntax, which I believe it does, it should work. It's a complicated chain, but this cljc library is included in a cljc application that uses shadow-cljs to produce a browser artifact (using :target :esm), a webworker artifact (using :target :esm), and a node artifact (using :target :node-library), and a jvm artifact.

I may need to change the node artifact build to use :target :esm too, but I've got some time to fiddle.

if its a CLJS lib the story is entirely different and none of the JS information applies

Oh! So, I can just slurp it and be done?

no.

as I just said. you need something that puts the file into a web accessible location

shadow-cljs doesn't support that

what kind of files are you talking about here?

Can you elaborate on what a "web accessible location" means?

> to produce a browser artifact

so the browser needs to be able to access it via HTTP, however you deal with that. eg. your public folder

No, this functionality will not work from the browser, it's server side only. Something like this:

#?(:cljs (if (browser-runtime?)
           (throw (ex-info "Not supported" {:sorry :dude}))
           (read-static-asset))
   :clj (read-static-asset))

I don't know what you are asking anymore. what do you want to do? do you need it accessible in the browser or not?

is the client loading it or is the server providing it?

According to some previous statements, the library works everywhere, including browsers. The static asset will be used only on the server side - on JVM, on Node via CLJS, on Node via JS.

Maybe the "on Node via JS" part is incorrect though, since I see that above ESM modules are mentioned only in the context of a browser and a web worker.

Sorry for the confusion - I'm building a nodejs application, that uses this cljc library, which needs to read a giant data file off of the filesystem. I need a way for this cljs asset to be accessible to another cljs application that produces an artifact that runs in Node on the server.

^you got it right, @U2FRKM4TW

I don't think how I'm packaging the browser/webworker artifacts is relevant

ok, the solution is not gonna be fund if the same code runs everywhere

there should be some node specific code that is only actually executed in the node env

if the same code is used for the browser this is not gonna work

Right, the same code will not be used for node and the browser - I've got a :closure-defines that will remove all of the node-specific code during a dead-code-elimination pass.

that doesn't work in this case

also are the library consumers aware of this closure-define?

hmm, no

I see what you mean

Does a runtime check work?

no

Alright, back to the drawing board. Thanks for walking me through it. 👍

I would recommend writing a clojure implementation in its own namespace

and a node implementation in its own namespace

do not use .cljc

and consumers of the lib just chose what they need