can I make shadow-cljs only bundle parts of javascript that is required? or should I use double bundle with webpack instead?

@doglooksgood not sure what you mean. shadow-cljs always only bundles javascript that is required?

@thheller I see, I means sometime a javascript file may include other files. like

require A from "a";
require B from "b";

module.exports {
  a: A,
  b: B
}

But in library like https://github.com/FortAwesome/react-fontawesome#explicit-import It is said, when using webpack, explicit import will let you to only bundle what you need. import { faCoffee } from '@fortawesome/free-solid-svg-icons' only include the faCoffee, even though '@fortawesome/free-solid-svg-icons' represent a index.js that require all files.

@doglooksgood yes that style is not supported. however you can probably just do ["@fortawesome/free-solid-svg-icons/faCoffee" :as faCoffee] (maybe :default not :as) to get the same effect?

Yes, I can use this way

Is it possible to use closure compiler to optimize javascript library, or how can I know if a library can be optimized by closure compiler?

if the library is purely strict ESM and only have strict ESM dependencies then in theory it can be optimized by the closure compiler

in practice at least on npm that never happens

eg. react/react-dom is not provided as strict ESM

ESM means ES module?

yes

I just curious about, what if, ClojureScript do dead code eliminate by its compiler and don't rely on closure library and closure compiler ? is it a good direction in your sight?

in theory that would be nice yes. in practice it doesn't work with a very large percentage of npm packages (I'd guess 90%+)

if they ever get their act together and follow the standards then maybe that gets better over time. today it is not practical

emm, why you think it doesn't work with most npm packages?

I don't think .. I know 😛

reasons vary .. either they include "dynamic" code that isn't compatible with the closure-compiler

most of them ship as commonjs without strict ESM compatibility

or just include some transpiled garbage ...

you can try setting :js-options {:js-provider :closure} in your build config

that will make everything go through closure-compiler :advanced compilation

it has not worked in a single build I have tried

you can sort of get it to work with lots of manual tuning

but that is rarely worth the effort

If react and react-dom not work with closure compiler, my build will never work:joy:

If ClojureScript drop closure compiler, and act like a babel transpiler, is it possible?

typo, label -> babel

sure, if you want to drop the closure-compiler. I have no interest in that.

I don't see closure library is wildly used by clojurescript programmers and libraries. It almost provide everything but just not be considered as mainstream, and looks like few people and libraries use it.

its not about the closure-library. it is about the closure-compiler.

most people see it as a negative for some reason. for me its just positive so I have no interest whatsoever in efforts to replace it.

I think closure library is part of the value of closure compiler?

yes, it is a bonus

you mean closure compiler provide optimizations, that's good choice, no matter use closure library or not, you will still use closure compiler?

yes

make sense.

FWIW I think it would have some value if the CLJS compiler just emitted strict ESM code

that would open up more tool options

but I would under no circumstance get rid of the closure-compiler in my builds

but many things we love in clojurescript and rely on are not possible with strict ESM code (eg. hot-reload, REPL) so it would need to be transpiled to something else to enable that

which brings us basically back to where we are now 😛

Three years before, the hot-reload is a magic, but know it's just a standard. Almost every JavaScript toolchain support that.

dunno ... last time I tried it really didn't work all that well

but its been a while so presumably things got better

I don't have any experience of F# and Fable(F# on JS), but how fable work is just implement a loader, and configure it in webpack.

{
        test: /\.fs(x|proj)?$/,
        use: {
          loader: "fable-loader",
          options: {
            babel: babelConf
          }
        }
}

you seem to see webpack as a positive. I don't 😛

if you want to build a loader go do that. many people would be interested in that I think.

I don't think webpack is positive, it's too complex. But sometimes I still need that simply import some css or fonts.

I made comments about why I'm not interested in webpack loaders in the past so you should be able to find it

alright

yeah we need a good tool for importing css or fonts

there are several levels, for I) I don't want use JS syntax, II) I don't want use JS build tool, III) I don't want use JS lib repository(npm), IV) I don't want JS dependency

😂

yep, some npm access is nice but it is never my preferred choice 😛

Hi, I'm trying to put in place some test and I would like to know which namespace shadow-cljs found when it scan my project. Is there a way ask which test namespace has been found by shadow-cljs?

@fabien.rozar ask how? I mean do you want to ask "does namespace x.y.z exist?", meaning direct lookup by name?

For what it's worth I just use shadow.resource to load CSS into my app

I wrote something small akin to style-loader and just use that

https://gist.github.com/tekacs/302eb450f99b511e609ca54de48eeb5e @doglooksgood

should be easy to do something very similar for fonts, etc.

@tekacs thanks! The idea is load the file in macro and insert into <script> in runtime?

right

so rc/inline pulls the file into the build

and tracks it as an incremental depenency

so that if you change the CSS it instantly reloads

and then the rest of the code simply puts it into the head as a script tag with a sourcemap

great, how about the untrack? I mean, when my code don't rely on a CSS file

sorry, what does that mean?

you mean unloading it, or ensuring that it's not pulled in?

yes

I guess shadow use this internally, so it should be okay.

finally I could get rid off webpack.