BuckleScript https://github.com/rrdelaney/bs-loader
PureScript https://github.com/ethul/purs-loader
Elm https://github.com/elm-community/elm-webpack-loader
Fable https://github.com/fable-compiler/Fable
Exception:
No Webpack for ReasonML https://github.com/chenglou/reason-react-example/blob/master/webpack.config.js
Can we make a loader for ClojureScript?
Or how about the possibility? I guess Closure Compiler will get in the why. But is it possible if I don't use dead code elimination from Closure Compiler? I know many people need it but seriously no other solutions? And how much does ClojureScript depend on Closure Library?
What would you expect from a loader that you'd be willing to give up the Closure Compiler?
Unhappy. Bundling ClojureScript projects is a pain since we have to use both JVM(or Lumo in near future) and Webpack(for CSS and images). And we have to use 2 package managers, npm and Clojars. It might not be a big deal for a Clojure developer who accidentally write web pages, but it's heavy work for front-end developers to use 2 sets of toolchains for our projects.
Nowadays Webpack contains lots of features for real world projects, like long time caching, async loading, assets bundling, with all kinds of loaders, that are not supported(or polished) by Closure Compiler. And that also means many companies who use Webpack just need them.
--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
This looks very nice, with a colleague here we event went as far as thinking, what if we completely drop GCP support for node.js targets.
We talked about this a bit on Clojurians, I like your idea to get closer to the node way. I am not a JS dev at all, but I understand the pain of existing JS devs when they approach the ClojureScript world.
They need to change everything they know, not only learn a language but also new (JVM) tooling. Many say no thanks, which is a pity because they are missing out :D
I have recently worked on a POC using Reason. The tooling is rough but it fits the JS ecosystem. The compiler is super fast (faster than Typescript even on my machine!). We ended up picking Typescript because of the tooling basically for a zero version of our stuff. I already don't like it that much ah ah.
That is incorrect. It is a pure Clojure library with no dependency on leiningen. I just happen to use leiningen and do not know enough about boot to create proper instructions for boot.
You can use it via the REPL
BOOT_CLOJURE_VERSION=1.9.0-alpha15 boot -d thheller/shadow-devtools:1.0.20170512-13 -s src repl
(require '[shadow.cljs.devtools.api :as cljs])
(cljs/once :build-id)
https://github.com/thheller/shadow-devtools/wiki/REPL
Some ideas in boot don't play too well with the design I have in mind for shadow-devtools but you can use it just fine.
Not by me but the features could certainly be ported.
I spent quite a bit of time yesterday fighting through webpack sources trying to come up with an efficient way of doing things.
The easy solution would be to make everything one-way which means JS can require CLJS but CLJS cannot require "local" JS, only modules from npm. So (js/require "react") would work but (js/require "./foo") would not.
So in JS you would could say var x = require("webpack-cljs/cljs.core"). The way things are handled in webpack/npm means you must have a module-name which would be webpack-cljs or something along that line. But a package cannot depend on the local sources.
Having sources to actually be side-by-side doesn't mirror too well to JS since you usually don't have namespaces there.
Imagine
src/index.js
src/foo.js
src-cljs/foo/bar.cljs
In index.js you could say require("./webpack-cljs/foo.bar") and in the cljs file I could imagine
(webpack/require "./foo") where it would always be relative context root (ie. src). The compiler would actually just generated a src/webpack-cljs/foo.bar.js. Same way it would for the module version.
The problem with that is that people may start writing npm packages in CLJS where each package would contain its own version of cljs.core. That would be really really bad.
Ideally I want
src/index.js
src/foo.js
src/foo/bar.cljs
but have not figured out how to do that yet. webpack has a ton of mutable state all over the place so trying to figure out what is going on is not that easy.
I'll probably write the simple version today and see how things work out.
So the simple version sort of works.
http://thheller.com/webpack-cljs-preview/index.html
http://thheller.com/webpack-cljs-preview/bundle.js
This was generated by "webpack -d" and
index.js:
---
var foo = require("webpack-cljs/dummy.foo");
console.log(foo.bar());
---
dummy/foo.cljs:
---
(ns dummy.foo)
(js/console.log "dummy.foo")
(defn bar []
"bar")
---
Nothing special but works well enough, still haven't figured out most of the webpack things though. Currently they shadow-devtools just runs independently and generates files into ./node_modules/webpack-cljs/dummy.foo.js to make the require "pretty" (I really do not like relative paths).
Will polish things a bit and maybe provide a public repo tomorrow. Still convinced that this is a very bad idea though. ;)
You can find an example here:
https://github.com/thheller/npm-module-example
I'd be very interested in feedback from people that actually use webpack already.
[1] https://groups.google.com/forum/?fromgroups#!topic/clojurescript/AGXku7Ous0Y
haven't followed this thread but david nolen just wrote a new article about webpack and cljs here:
--
I read that post on ClojureVerse. With shadow-cljs it already very trivial to use React by writing `["react" :as React]`. Importing standalone JavaScript files is easy too with https://code.thheller.com/blog/shadow-cljs/2017/11/10/js-dependencies-in-practice.html . Using Webpack is too much steps.
On Thu, Jun 14, 2018 at 11:00 AM daniel sutton <daniels...@gmail.com> wrote:
haven't followed this thread but david nolen just wrote a new article about webpack and cljs here:--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscribe@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscribe@googlegroups.com.
I think the guide demonstrates quite clearly it's very trivial with ClojureScript now. People can easily add templates (via cljs-new), or create a la carte libraries that automate the small number of steps.DavidOn Fri, Jun 15, 2018 at 2:46 AM, jiyinyiyong <jiyin...@gmail.com> wrote:
I read that post on ClojureVerse. With shadow-cljs it already very trivial to use React by writing `["react" :as React]`. Importing standalone JavaScript files is easy too with https://code.thheller.com/blog/shadow-cljs/2017/11/10/js-dependencies-in-practice.html . Using Webpack is too much steps.
On Thu, Jun 14, 2018 at 11:00 AM daniel sutton <daniels...@gmail.com> wrote:
haven't followed this thread but david nolen just wrote a new article about webpack and cljs here:--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
--
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.