probably should just write the externs, makes the code a lot cleaner.

You can write your own externs, I don't know if you knew that. It's not that hard, although figuring out the tooling takes a few hours

here's an example of an externs file I wrote four PouchDB

var pouchdb = function() {};
pouchdb.plugin = function() {};
pouchdb.plugin().auth = {};


var auth = {};
auth.default = {};

var perms = {};
var pfind = {};
pfind.default = {};

var pmemory = {};
pmemory.default = {};

pouchdb.logIn = function() {};
pouchdb.changes = function() {};
pouchdb.changes().on = function() {};
pouchdb.createIndex = function() {};
pouchdb.get = function() {};
pouchdb.put = function() {};
 = function() {};
pouchdb.remove = function() {};
pouchdb.allDocs = function() {};
pouchdb.find = function() {};
pouchdb.sync = function() {};
pouchdb.sync().on = function() {};
pouchdb.destroy = function() {};
pouchdb.bulkDocs = function() {};
pouchdb.getAttachment = function() {};

although strangely enough, I haven't had to write externs like that since I started using shadow-cljs according to the guide. But that's what I used when I did figwheel

@U7PBP4UVA is this how you are importing your javascript? https://shadow-cljs.github.io/docs/UsersGuide.html#_requiring_js

Yes, requiring js files. For anything else I have :infern-externs :auto and just annotate with ^js as prompted. But for literal js files I get no warning, only runtime errors.

are those 3rd party libs or your libs?

I'm just curious b/c I haven't had that issue for some reason and I use external js extensively

The JS files are utility code that invokes ProseMirror stuff.

e.g.

if (parent && parent.type.allowsMarkType(type)) {

hmmmmm

maybe try turning off :inter-externs

b/c that shouldn't be renamed, or if it is renamed, it should be globally renamed

It can't be globally renamed, since it's using an npm dependency

do you have a precompilation step like webpack?

No, just shadow cljs

otherwise it seems to just paste all the code into one file then aggressively rename stuff, so I wouldn't see why it wouldn't be globally renamed

well one way you can check is to turn off renaming

:pretty-print true

somewhere

Yep, it's on my list, I'm trying to reproduce the exact reported bug right now 🙂

lol I love telling people things they already know, it's so much easier than doing my own work 😅

https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options

there is no externs inference for JS files. so it is expected that allowsMarkType would be renamed

you can sort of figure out what the original name is by using shadow-cljs release app --pseudo-names

I use --debug

yeah, that works too

an alternate is to not feed the JS files through :advanced. you do that by changing them to commonjs

meaning require/module.exports instead of import/export

only ESM JS files go through advanced, regular commonjs is processed like all other npm files (ie. only simple)

Ah, using common.js is easier than trying to write externs, thanks @U05224H0W - why should ESM files be advanced though? Is there the expectation that an npm library that produces ESM will also get renamed?

well you lose some stuff by going to commonjs. the files can no longer import CLJS code directly

so ESM is preferred and recommended

writing externs also takes like 5min https://shadow-cljs.github.io/docs/UsersGuide.html#_simplified_externs

well I guess that depends on how it takes for you to find them 😉

ProseMirror actually has a well-defined Typescript API, not sure if that's consumable somehow

But the actual use case I have for JS files is mainly copied code that is too cumbersome to rewrite to CLJS 😄

there is not no

I mean there could be a tool that collects all property names in JS files and just adds them to externs

wouldn't be totally accurate since not everything needs externs but could be useful

turning of all renaming unfortunately makes the build rather large, since CLJS generates rather long property names for stuff

http://www.dotnetwise.com/Code/Externs/ https://www.npmjs.com/package/tsd2cce FYI

oh the second might be useful but be sure to check the build size after

generating too many unneeded externs can have negative effects if you care about build size at all

Thanks @U3BALC2HH @U05224H0W - for now I'm just converting my handful of JS files to common.js, ProseMirror has a large enough API surface to make writing externs for it a nuisance. Most of our code is using it from CLJS anyway, the JS files are mostly utilities.

something like retrieving the repl environment by build id

(shadow.cljs.devtools.api/cljs-eval :app "(js/console.log ::foo)" {:ns 'foo.bar})

nice! thanks!

@U05224H0W is there an easy way of getting that build-id env? so I can call things like cljs.analyzer.api/resolve, which requires the env

(shadow.cljs.devtools.api/compiler-env :app) but its not the env required for resolve, its the compiler env usually bound to cljs.env/*compiler* atom

I think there is a cljs.analyzer.api/with-compiler-env macro or so where this would go

thanks a lot! will try to experiment with that

That's great! Would love to hear a bit more about what changes you made in your config as well as any shadow-cljs changes you're aware of that contributed to the dramatic decrease in bundle size

probably only this change https://github.com/thheller/shadow-cljs/commit/723fbf0075c8a06ba452104b61fb97ca6609f573

with using :js-provider :import (ie. shadow-cljs not in charge of bundle npm dependencies)

JS tools have better tree-shaking for npm deps than shadow-cljs currently

Yep! We're using :js-provider :import along w/ webpack and the commit above made our webpack bundle much smaller 🎉

Awesome! As an aside, we are currently lazy-loading modules in our app. Do you think a similar change would benefit us? It's been a while since I revisited this, but if I recall correctly, :js-provider :import bundles all npm deps into a single file to be fed into the external JS bundler. Since modules are loaded all or nothing, would this mean all our deps would be loaded as soon as our first "app" module required a dep? in a lazy-loaded/code-split environment, the benefit is not as clear-cut right? maybe it's still worth the reduced bundle size -- i might have to experiment 🙂

From my understanding, :js-provider :import doesn't do any bundling of the JavaScript dependencies and instead leaves that to some other tool (in our case webpack).

Ah yes, sorry I used "bundle" incorrectly. I meant to communicate that shadow-cljs puts all of the JS require calls (dependencies) into a separate file, then lets the external tool do the bundling/tree-shaking

Ahhh, we're not doing code splitting yet so I'm not sure how it would work w/ that. If you do end up experimenting some, would be interested in your findings!

@UGGU8TSMC you are thinking of :js-provider :external. thats different. :js-provider :import fully supports code splitting as well, :external puts all JS deps in one file and is not splittable

whether or not you'd benefit by :import depends on the npm deps you use. not all are tree shakeable

Ah thank you for clearing that up!

Sorry for the obtuse question but how would I get started using :js-provider :import over :js-provider :external would I just need to hand roll a js file for the requires? I’m not sure how they’d be exposed to shadow-cljs. I’ve got a 1mb production artifact I’m convinced could be split down some.

The way I did it was I created a webpack config with the entrypoint being a javascript file looking like this. main corresponds to the module that I have defined in my shadow-cljs.edn file.

if (process.env.NODE_ENV !== "production") {
  require("./.shadow-cljs/cljs-runtime/shadow.cljs.devtools.client.browser.js");
}
import init from "./.shadow-cljs/main.js";
init();

I don’t suppose you have anything on github I can look at? 😄 Does this mean that the requires within the shadow-cljs app are picked up by whatever js build tool? That’s nice. That’s very nice.

I actually wrote a note to put together a blog post with what I did since it's not part of an open-source project so will tag you when that gets done 👍 what I ended up doing was disabling webpack hot-reloading and I let shadow-cljs do all the reloading.

Awesome, if I wrap my head around it fully I’d write something myself. I do find some of the latter esm stuff a bit hard to understand at times 😅

@U2U78HT5G if all you need is to run init you can just use :init-fn in the build config. no need for exports then. also the extra conditional require shouldn't be required at all. you can just point webpack directly at the shadow-cljs output

Thanks! I'll make those changes to clean up the code a bit 🙂

Hi again, I just wrapped up the blog post this morning. I think I included all the changes I made as part of the migration but if anything doesn't make sense feel free to reach out! https://deh.li/2022/11/04/shadow-cljs-webpack.html

@U2U78HT5G please note that it is not necessary to have two builds like this. splitting dev/advanced build is already handled by the watch/release commands. the config can be the same for both builds

so in your case just

;; shadow-cljs.edn
{:builds
 {:web
  {:target :esm
   :output-dir ".shadow-cljs"
   :devtools {:watch-dir "resources/public"}
   :js-options {:js-provider :import}
   :modules {:main {:init-fn com.vistaly.web.core/init!}}}
  }}

on a second note though please consider using another :output-dir. the .shadow-cljs dir is for shadow-cljs internal runtime files and caches. at some point this may create conflicts and either create problems in your builds or shadow-cljs internally

release also sets goog.DEBUG false, so no need to specify it. it also defaults to :optimizations :advanced

thanks for your feedback! i will update the post. in actuality my output-dir is nested in another directory which is why I hadn't gotten any issues but I will make changes so people don't mistakenly clobber their internal runtime files

did you purposefully exclude :infer-externs :auto ?

its also the default

awesome 🙂

0.81MB compressed is so nice for an app that complex, congrats 🎉 is this having our cake and eating it too?