Clojurians Log v2

hm I’m thinking it’s meant to be done via bb.edn but since i’m compiling files via framework’s build process (webpack and metro), this would just be a separate step of creating bb compiled file with deps

ok seeing how nbb loads deps to see what could be done https://github.com/babashka/nbb/blob/df170a3a6bd7ec3ca009c39b207fc2f7d7dac925/src/nbb/api.cljs#L48 still wondering what the overall expectation is before going in on any one solution

oh wow did not know shadow-cljs recently released an esm target https://shadow-cljs.github.io/docs/UsersGuide.html#target-esm I still see value in having cljs exposed as npm module and not depending on google closure compiler, but this does alleviate some of the pain points Cherry was resolving

I wonder how difficult it’d be for shadow-cljs to integrate a cherry-cljs target

yes, cherry of course uses shadow with the esm target to build itself, so does #nbb

yeah, there's an issue for this here: https://github.com/squint-cljs/cherry/issues/64

not yet implemented

That’s specifically about local user namespaces not remote dependencies but they may* deal with same solution. I was fine* with specifying local cljs code by relative string path, as that made it easier to integrate alongside JS projects. Otherwise we would need typical namespace enforcement.. or perhaps some path to identify related files that get picked up with their namespaces read

Yes. Right now you can compile the file and then refer to it as the compiled JS. But I think later on we would need some kind of "out" folder for compiled libraries which gets added to the search path and files will be automatically compiled if they aren't already

remote deps could be precompiled but I think to integrate with js tools local namescapes would need to be handled on the fly and cached compileString could accept an option for finding namespace paths and validating their names I’m not sure how this impacts macros or the repl though

@borkdude Right now my priority is releasing current js project, so may not be right time to try to take this on as I don’t want to get too derailed with surprises. But so awesome to see what’s unfolding. For now if you’d like me to extract webpack loader logic into a Cherry example (or separate repo) to reference, let me know

i’m using next+webpack (since there’s better tooling for React Native/Web with it); but with Vite and vite-ssr-plugin could open up cool possibilities for ecosystem

Yeah, I think that would be helpful, we could just link to a repo that you manage

It's a bit early days and I want to flesh out some organisational issues like where does the code of cherry/squint and compiler live, before tackling some of the other issues (REPL, code loading)

Yeah totally. May make since to consolidate repos completely as now issues are spread out too. The monorepo management on CLJS side isn’t great but for JS it is, in case that’s a route you’d like to go and need assistance setting any of that up

I'm losing the github stars from the other repos then :(

pick the repo with the most stars? 🙂

when I extract webpack logic, I can try to give a monorepo example for compiler-common a go if that’s something you’re considering

can just devote an evening to all this

> I want to flesh out some organisational issues like where does the code of cherry/squint and compiler live i guess I don’t know exact frustrations you’re experiencing, but did see that you’re treating code in compiler-common as three separate projects

the reason I did that is that when you make a PR against compiler-common, you know if it will break either cherry or squint

I'll probably make compiler-common a library like SCI and will then depend on that in cherry / squint (like babashka / nbb depend on SCI)

but for that to happen I have to move more code to compiler-common first

and then move some wrapper code back to cherry / squint

example isn’t fully working but i did extract the logic in case anyone follows this trail https://github.com/alidcast/next-cherry-cljs-example

cool, thank you!