Add support for coffeescript

[mb5]

CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

It would be nice to write greasemonkey scripts directly in CoffeeScript, it is mich nicer to write and maintain than JavaScript.

[arantius]

I really don't see this happening. You can write CoffeeScript and compile it to JavaScript just fine today, and everything works. This would be a lot of complexity to add in order to support a very niche use case.

You could probably write an @require that would export a function that loads the CoffeeScript source from an @resource and then compiles it down and executes it. If we were going to provide this feature, that's essentially what we would do. And our policy has long been not to add features into GreaseMonkey core that script authors can implement themselves.

[flying-sheep]

please reconsider: myscript.user.coffee would gain syntax highlighting unlike a solution that involves compiling and evaluating a multiline string, and, also unlike the latter, it wouldn’t need boilerplate.

i can’t see how a simple @require circumvents the execution of the userscript as javascript (and the resulting syntax error)

finally, scripts distributed as coffeescript (unlike the compiled javascript) are better to read and learn from, and don’t need extra effort in terms of linking the coffee script source and using build tools. one would simply fire up the user script editor, tick the “coffeescript” checkbox and hack away, which is perfect for userscripts because of coffeescript’s terseness compared to JS.

[marnen]

@flying-sheep I think the point is that you'd @require the CoffeeScript compiler, and then load the Coffee source as a @resource -- which doesn't get executed like a @require does.

[marnen]

@arantius That said, I don't think CoffeeScript is a niche use case. Many serious JS developers (myself included) far prefer CoffeeScript syntax. I like your @resource trick, though, and I may well try it on an upcoming project.

[flying-sheep]

hmm, so you create a generic wrapper like this, and upload the real script somewhere?

// ==UserScript==
// @require http://jashkenas.github.io/coffee-script/extras/coffee-script.js
// @resource coffee http://url-to-real-script.coffee
// ==/UserScript==

CoffeeScript.eval(GM_getResourceText("coffee"));    

well, this could work, but i’d by far prefer not to have to upload the real script elsewhere, and have to navigate there to edit it, and force the wrapper script to update by changing the url to the real script twice. this is all hackish and bothersome.

[marnen]

@flying-sheep You're right, that would be a pain, and I can't think of any other sensible way of doing it (except having the CoffeeScript source code within a JS string, which seems annoying in other ways).

@arantius I think this discussion goes to show that in fact, this is not a feature that script authors can conveniently implement themselves, and I think it would be useful to many people to have *.user.coffee Just Work as *.user.js does. Therefore, I now believe this is a suitable candidate for inclusion in Greasemonkey core, and that the issue should be reopened.

[hen-x]

I've found a passable(?) workaround for embedding CoffeeScript code within JS — embedding it in block comments. It can be extracted using a regex and then compiled.
First we @requirethe compiler, then invoke it like this:

CoffeeScript.run('' + /#[^]+/.exec(function() { /* #
    alert "Your CoffeeScript code here!"
    for i in [1..3] console.log "Multiple lines of code within a comment block"
# */ }));

[marnen]

@sethaurus I wouldn't call that a passable workaround, if I understand the syntax. I'd call it a clever but ugly hack. :) Among other things, I doubt that any editor will deal nicely with it...

All of this becomes unnecessary if Greasemonkey supports .user.coffee. I've said this before and I'll say it again: this is not a feature that script authors can easily implement for themselves. We need core support; the recent example in #1738 is a step in the right direction, but doesn't go far enough.

[alesch]

+1 for @marnen.

[weakish]

Just learned another approach, which also using eval:

//;###
// ==UserScript==
// @name        coffeetest
// @namespace   http://example.com/coffeetest
// @include     *
// @grant       none
// @require     http://coffeescript.org/extras/coffee-script.js
// @version     1
// ==/UserScript==
CoffeeScript.eval((function(){/*
# coffeescript from here ###

class User
  constructor: ->
    @name = 'Coffee'

  call_name: ->
    alert "Mr. " + @name

(new User()).call_name()

# end of coffeescript #*/}).toString().split("\n").slice(1, -1).join("\n"));

via qiita.com/tomoemon

[marnen]

@weakish @sethaurus That's kind of clever, and I suppose it's meant to get around the lack of generic quoting constructs in JavaScript. However, it still breaks syntax highlighting because to the editor, the file is a JavaScript file, not a CoffeeScript file.

To Greasemonkey maintainers: is there any actual objection to including native .user.coffee support in Greasemonkey, or is it just that nobody's got around to implementing it yet? (@arantius had originally said that it wasn't necessary for the Greasemonkey environment to provide it, but the fact that we're reduced to all these hacks clearly shows that that isn't in fact the case.) If the latter, I'll think about putting together a pull request.

[weakish]

However, it still breaks syntax highlighting because to the editor, the file is a JavaScript file, not a CoffeeScript file.

@marnen If you manually set the file type to coffeescript, you have right syntax highlighting (except for the first line.) You can also modify your editor/IDE's file detect, say, considering a file whose first line is //;### CoffeeScript.

However, I think .user.coffee is much cleaner.

[marnen]

@weakish Yes, that's really what I was saying. I think .user.coffee should Just Work.

[yi]

+1 for .user.coffee

[pyhedgehog]

-1
If it's compiler, it should be run on developer side.

[cletusc]

-1.
Coffeescript compiles to native JS, and should continue to be compiled on the script author's side (or use one of the methods described above). Let's say GM implements this, and Coffeescript updates, GM is now responsible for making sure the compiler is up to date and whether a compiler update is backwards compatible otherwise script devs will complain that GM broke their script.

Do it on the dev side, not GM side. It gives you more control as a developer and keeps GM on the path of preferring native solutions over GM-provided solutions.

[marnen]

@cletusc @pyhedgehog Really? You want every userscript to have to bootstrap the CoffeeScript compiler, rather than including it once in GreaseMonkey? That might be OK if GM provided for including external libraries (like the CoffeeScript compiler) or other external script files (like the actual CoffeeScript userscript source code), but GM doesn't do that very well (or didn't the last time I looked at doing this -- @resource is not adequate).

I assure you that if this were something that could be easily done on the dev side, I would have done it long since. But it isn't, even though it looks like it should be until you try it. :) OTOH, it is something that would require only 1-2 lines of code on the GM side (and inclusion of the CoffeeScript compiler as a library) -- I looked into submitting a pull request for it not long ago (though I ultimately didn't have time to do so).

I do understand your concern about GM updating the CoffeeScript compiler and "breaking" existing scripts. But that seems like it would be easy to deal with compared to the current awful workarounds for the lack of .user.coffee support. Remember that userscripts are supposed to be easy for users to write (and CoffeeScript is arguably easier than JavaScript to write well). When the workflow starts including precompilation, it stops being an easy workflow.

[pyhedgehog]

@marnen No. I want to generate .userjs from .cofee and publish it.

[flying-sheep]

not the only workflow. others include using greasemonkeys builtin editor

[pyhedgehog]

GreaseMonkey allows you to use any other editor - use one that you can configure to edit source and run compiler.

[pyhedgehog]

However there are place for addon to greasemonkey that can precompile .usercoffee scripts. And possibly any other addon - i.e. to precompile .userjava with GWT. There are place for any addon that use generator to JS, but why you want to push it to greasemonkey?

However such development can require feature-request for some hooks in greasemonkey such addon can use.

[marnen]

@pyhedgehog I wasn't aware that GM supported addons. If that's the case, then that seems like it's probably a much better place for .user.coffee support to go.

[flying-sheep]

GreaseMonkey allows you to use any other editor - use one that you can configure to edit source and run compiler.

you don’t understand: this still means that the user will edit the compiled JS code, not the coffeescript source code.

---

about addons: well, could you point us in the direction of APIs that allow such a thing?

[pyhedgehog]

@marnen As far as I know it doesn't. But anyone can write Fx addon that uses GM objects and functions.
So I propose to investigate such addon requirements and convert this issue to request for needed hooks and exported functions.

@flying-sheep If properly configured - no. GM passes to external editor path to local storage of .userjs. If there are .usercoffee nearby editor can catch it and regenerate .userjs on the fly. It's easy to write such a wrapper even for a notepad. And even easier to configure editor that supports plugins.

[flying-sheep]

why should there be a .user.coffee nearby if the script was obtained via some userscript hoster?

sorry, but nothing will be as convenient as simply handling .user.coffee in greasemonkey.

[pyhedgehog]

Why you need to edit script you have obtained via some userscript hoster?

There are two different workflows - developer and user. User should get compiled version (i.e. .userjs file). Developer should be able to configure it's own testing/development environment to edit source (any source - coffeescript, livescript, toffeescript, ruby, python or any other). You want GM to integrate them all? Let's start with Blockly?

[flying-sheep]

There are two different workflows - developer and user.

wrong, i often tweak scripts i have downloaded. and i don’t want to fork a repo, figure out the build system, and then start editing.

You want GM to integrate them all?

of course not. coffeescript and maybe babel should be more than enough (remember: this is about conveniently editing small userscripts, not big applications where type safety would be beneficial)

[pyhedgehog]

Why you think it should be inside GM? Why not another addon?

[flying-sheep]

if that’s feasible and GM offers the required API hooks, fine, but i’m going to have to see that before agreeing that it’s the best alternative.

[joech4n]

Does the code provided in #1529 (comment) work for still work for anyone else? I can't seem to be able to get it to work.

I am using @require https://raw.githubusercontent.com/jashkenas/coffeescript/master/lib/coffeescript/coffeescript.js instead of @require http://coffeescript.org/extras/coffee-script.js.

Update: Looks like I need to use @require http://coffeescript.org/v2/browser-compiler/coffeescript.js per CoffeeScript docs. Here's an updated working example.