cljs-dev

ClojureScript compiler & std lib dev, https://clojurescript.org/community/dev
dnolen 2020-04-11T00:00:44.294700Z

looks great! left a comment

dnolen 2020-04-11T20:02:49.295500Z

well that was easy - the bundle stuff just works - very minor change

dnolen 2020-04-11T20:03:23.296400Z

I could make a project that used react & react-dom no config, run webpack - dev and advanced worked fine

👀 1
dnolen 2020-04-11T20:04:30.297300Z

the way this is done - zero impact on any existing tooling - since it doesn't really change anything at all - it just makes it easy to run webpack on our output

dpsutton 2020-04-11T20:17:45.298300Z

Do you have one of these repos publicly as an example?

dnolen 2020-04-11T20:21:58.299100Z

not yet - there's a couple of other UX things I'd like to think through

dnolen 2020-04-11T20:22:01.299300Z

but this is really zero config

dnolen 2020-04-11T20:22:27.299600Z

{:main cljs-bundle.core :output-to "out/index.js" :output-dir "out" :target :bundle}

dnolen 2020-04-11T20:22:57.300200Z

that's it, :bundle handles all the options you need for you

dnolen 2020-04-11T20:23:20.300900Z

the output file can be handed over to whatever bundler that understands require that you want to use

dnolen 2020-04-11T20:23:54.302300Z

no custom index.js, no manual :global-exports

dpsutton 2020-04-11T20:23:57.302500Z

Because of figwheel and shadow I’ve never used webpack beyond the simple example on http://clojurescript.org. So was interested in the whole thing if you already had it made

dpsutton 2020-04-11T20:24:22.303100Z

But very excited for this direction. Thanks for the thinking and the work

dnolen 2020-04-11T20:24:43.303700Z

to clear the above is bigger than just usability as I've said before

dnolen 2020-04-11T20:25:15.304400Z

you can now publish a CLJS JAR that use node_modules and people can consume it and expect it to work reproducibly

dnolen 2020-04-11T20:25:23.304600Z

across all tools

dnolen 2020-04-11T20:26:53.305Z

note this means also making something that works for React Native (outside the REPL bits) is trivial

dnolen 2020-04-11T20:27:02.305300Z

because it's exactly the same as webpack

dnolen 2020-04-11T20:46:44.306700Z

it's definitely something I found disconcerting about the existing CLJS RN integrations (except probably shadow) - overly complicated because there wasn't access to a few important things

👍 2
dominicm 2020-04-11T21:35:56.308Z

RN will be huge. For live reloading, will that now be down to the bundler to provide? And do I need to run clojurescript in auto rebuild to get that?

dnolen 2020-04-11T21:55:45.309200Z

in the case of RN (i.e. Metro) nothing - the CLJS tooling will need to do it

dnolen 2020-04-11T21:56:09.309700Z

but you can now focus on the parts that differentiate CLJS from JS dev

dnolen 2020-04-11T21:56:25.310200Z

CLJS works as JS tools expect for JS deps

dnolen 2020-04-11T21:57:43.310900Z

but I think a bigger impact for example will be shared wrapper for Reagent

dnolen 2020-04-11T21:58:01.311400Z

every Reagent RN project has this boilerplate around mapping RN components to Reagent

dnolen 2020-04-11T21:58:10.311700Z

that can just go away - you can make a dep now that people can just use

dnolen 2020-04-11T22:02:49.313800Z

what I'm looking really forward to is seeing people push more stuff that may be locked up in their apps that could be open source / reusable but there wasn't a practical way for it to work for a wide number of users

dnolen 2020-04-11T23:41:10.314300Z

@mfikes we should probably repurpose the :aot-cache stuff for project local files

dnolen 2020-04-11T23:41:40.314900Z

we end up doing a lot of work when switching between :none and :advanced which is uninteresting

mfikes 2020-04-11T23:42:18.315800Z

Oh, right. :advanced implies a lot of build-affecting options change.

dnolen 2020-04-11T23:42:31.316100Z

I think with that in place + the global :aot-cache I think most of the time could be spent only in Closure for advanced builds

dnolen 2020-04-11T23:45:50.316500Z

{:main cljs-bundle.core
 :output-to "out/index.js"
 :output-dir "out"
 :target :bundle
 :bundle-cmd {:none ["npx" "webpack" "--mode=development"]
              :default ["npx" "webpack"]}}

dnolen 2020-04-11T23:46:41.317300Z

added :bundle-cmd to master - with that in place running a :none build w/ REPL and :advanced build feels more or less like ClojureScript

👍 2
dnolen 2020-04-11T23:56:49.321100Z

I think the only feature that you will lose going down this path is optimal code-splitting, but after all the work that we've put into it still feel like something only hardcore user reach for.

dnolen 2020-04-11T23:57:44.322200Z

so I think it's a fair tradeoff - curious what folks think that are using CLJS directly w/ code-splitting and foreign libs (who would like the new convenience of the bundle approach)

2020-04-12T07:13:20.331500Z

Similar here, I use code-splitting a lot and is especially NB for browser-apps that consume NPM stuff (which can be large)