Re: how to inject a @preserve'd comment block

144 views
Skip to first unread message

Martin Weber

unread,
Apr 20, 2013, 12:10:01 PM4/20/13
to clojur...@googlegroups.com
Until a more elegant solution comes along, here's what I'm (successfully) using:

a) add a foreign-libs marker to your cljsbuild build spec (in case you are using cljsbuild), here's what I added:

:foreign-libs [{:file "comment-block.js" :provides ["comment.block"]}]

b) add that foreign "lib". Here's what mine contains:

/**
* @fileoverview
* This file contains nothing but a comment block which is to be preserved
* by the google closure compiler. This comment block contains a comment
* block which is necessary to be in the output of the compiled javascript
* even in advanced compilation mode.
*/
/**
* @preserve
// ==UserScript==
// @description Description of the user script
// @include INCLUDESPEC HERE
// @include ETC ETC
// @name user script name
// ==/UserScript==
*/

c) (require) your foreign lib. (require [comment.block :as ignored])

d) run your (advanced) compilation. Somewhere in the compiled output, the UserScript block will appear (note that the user script block requires to be at column 0, beginning with // style comments, which is why there's that newline after @preserve).

Now if you e) call the compiled output something akin blablabla.user.js, greasemonkey will recognize it, pick up the data from the user script block, and there's unicorns for everybody (even the vegans!)

So, this works, but it's ugly. Better alternatives, anybody?

David Nolen

unread,
Apr 20, 2013, 12:34:22 PM4/20/13
to clojur...@googlegroups.com
Perhaps adding something to the top (or bottom) of the output file is best handled at the level of tools like lein-cljsbuild? I'm definitely hesitant to add any explicit support for this into the CLJS compiler directly.



--
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 http://groups.google.com/group/clojurescript?hl=en.



Martin Weber

unread,
Apr 20, 2013, 12:53:50 PM4/20/13
to clojur...@googlegroups.com
On Saturday, April 20, 2013 12:34:22 PM UTC-4, David Nolen wrote:
> Perhaps adding something to the top (or bottom) of the output file is best handled at the level of tools like lein-cljsbuild? I'm definitely hesitant to add any explicit support for this into the CLJS compiler directly.
>

I can get comfortable with using the foreign-libs approach. Greasemonkey (at least) doesn't expect the user script to be a *header*, obviously, so my use case is helped right now. As you note, there might be a requirement for specific tools to emit a header or footer. The approach I took mixes the @preserved block somewhere in the middle of the file (although it does retain newlines, at least).

Is cljsbuild considered the canonical approach to clojurescript nowadays (in contrast to just-in-time compile services etc.)? If it isn't (or cannot, or must not be), the problem is not enough of an itch to scratch in the CLJS compiler, is what you're saying? I'm not familiar enough with the cljs->closure compile chain to say whether or not a cljs macro could be helped to do the job (completely orthogonal to whether or not it *should* be doing it, of course).

Anyways, I found a solution to my problem, the archives now have a solution that works, too, I'm moving on. If there ends up being support for generating portions of your output js, I'll happily move towards using those capabilities.


-Martin

David Nolen

unread,
Apr 20, 2013, 1:06:55 PM4/20/13
to clojur...@googlegroups.com
On Sat, Apr 20, 2013 at 12:53 PM, Martin Weber <ephaeto...@gmail.com> wrote:

Is cljsbuild considered the canonical approach to clojurescript nowadays (in contrast to just-in-time compile services etc.)? If it isn't (or cannot, or must not be), the problem is not enough of an itch to scratch in the CLJS compiler, is what you're saying? I'm not familiar enough with the cljs->closure compile chain to say whether or not a cljs macro could be helped to do the job (completely orthogonal to whether or not it *should* be doing it, of course).

cljsbuild is widely adopted yes. And now that it exists there's less reason to put even more stuff into the already complicated closure.clj file which builds the final output.

Glad you were able to find a solution that works for you.
Reply all
Reply to author
Forward
0 new messages