On Tuesday, January 6, 2015 1:20:04 PM UTC+2, Thomas Heller wrote:
> >
> > That's right but for some projects the assumption that .min.js means
> > "minified" is just not true. E.g. React ships with different logging levels
> > enabled based on wether you're including the development or production
> > build. I'm sure there are more projects that include extra debugging stuff
> > that's stripped while packaging.
> >
>
> You are right, I guess I'm too spoiled by CLJS/Closure that I don't have to
> worry about things like that. ;)
>
>
> > > As a build tool author I don't quite agree with using a naming convention
> > > to detect the files (eg. *.inc.js, ...). You could never package more
> > > than one file this way since there would be no way to tell the compiler:
> > > file Y needs to be added before file B.
> >
> >
> > Very fair point. We haven't actually come across that situation as most
> > libs are distributed as single files but I agree that this might cause
> > problems with libraries that are distributed with multiple files (Thinking
> > of Bootstrap - although that's a whole other beast).
> >
>
> I was thinking in terms of my project. The only external (non-closure) JS I
> use is CodeMirror. I have several different builds, most of them do not need
> CodeMirror. Yet CLJSJS (boot) would prepend it to everything. Also in my case
> not all builds use the same amount of CodeMirror (eg. one gets clojure-mode
> vs the other does not).
Using boot it's easy to filter fileset so that some of files are removed before
cljs task picks up the .inc.js files:
(sift :exclude #{#"^cljsjs/.*codemirror.*"})
But several different builds (different apps or modules) is indeed still an
area where boot will need some work. It should be possible to build several
apps from same sources etc. but all resulting js would contain all the same
shared code.
>
> This stuff is pretty complex, I don't think we can solve it by just creating
> a few jar files. We MUST address the fact that the produced JS files are
> shipped to clients (ie. browsers) a lot, therefore we must take great care
> that they don't contain unnecessary stuff. Shipping CodeMirror to everyone of
> our users would be a disaster since it is only used for backend/admin stuff.
One way would be to build your admin/backend application as a separate app
which would have it's own maven dependencies. Or, using boot, it's possible to
remove and add maven dependencies as build steps.
So there are ways to control what gets included to build but it's manual work
as there is no way to know what external code is actually used by the built js.
I think the greatest problem is that there exists libraries which are pretty
useless without custom built step (e.g. Highlight.js is one I encountered).
CodeMirror modes and add-ons is also such one. I'm not sure how it should or
could be packaged.
>
>
> /thomas
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
