CoffeeScript 1.6.0 released with support for source maps | Hacker News Reader

CoffeeScript 1.6.0 released with support for source maps

coffeescript.org

240 pointsazylman77 comments

I hope some of you find 'em useful ;)

Please direct all thanks for this over to http://github.com/jwalton. He's been toiling away on these for a couple of months now, originally as a bit of a skunkworks. Managing to get them merged in cleanly to an oft-changing code generation codebase was no small feat.

Edit: If you're having any trouble getting these to work, `npm cache clean` and reinstall. I screwed up the initial publish.

Absolutely fantastic! Though it is fairly easy to manually map the javascript source line to coffeescript code, I am hoping this feature can somehow be embedded into editors to make it much easier to write large coffeescript modules (live coding).

Can source maps handle source files in a different location than the compiled JS file? In my few minutes after installing, I didn't immediately see a way to do this.

Can't edit anymore, so I'll just reply to myself.

Important Update: Just pushed out a 1.6.1 release which patches some bugs that snuck in this morning. Give it a spin.

It also makes it possible to generate source maps in the browser itself -- so if you're doing anything fancy with eval-ing CoffeeScript on the client side, you're in luck...

... now, time to hit the road.

Thank you very much for this! Coffeescript has certainly come a long way since I started using it on version 0.9.4, 2 years ago. Congratulations!

Wow, that's great. And merely a week since 1.5!

> CoffeeScript includes a (very) simple build system similar to Make and Rake.

Arrrrrrrrrrrgggggghhhh.....

Why do people insist on doing this feature creep nonsense? Just stop! The world doesn't need another build system. The fact that you personally don't understand make (or cmake, or autotools, or rake, or scons, or ant, or...) is not a good excuse for inflicting another one of these things on the rest of us.

Yes, I'm sure it meets the needs of the coffeescript project nicely. But what introducing it has actually done in build a brand new barrier to those who want to work on coffeescript. You're ghettoizing your project with this nonsense.

Also: just for the record, those "cakefile" examples look awful to me; modulo language syntax, it looks just like scons. Everyone who has ever tried to use it for something serious hates scons.

This isn't new, CoffeeScript has included this for a while.

One thing to keep in mind is that Cake is tiny, the complete source shouldn't take more than a minute or 2 to read and understand[1] and is a nice example of CoffeeScript style.

[1]: http://coffeescript.org/documentation/docs/cake.html

You're right that it's not new in 1.6; I misread the page. It was new to me, however. And you're right that it's quite small, and easy to read.

Which allows me to pronounce that It's tiny because it's limited. What happens when the project bumps up against those limitations (parallel builds would be nice, or maybe default rules, or the ability to invoke and export environment variables to subprocesses, or...)? Will they abandon cake and move to a build system that already meets their more advanced needs?

Hell no. They'll add features. So the cake of 2019 will, assuming a still-robust coffeescript community, look a lot more like rake or ant or scons or cmake. It won't be tiny. It won't be easy to read. It will be yet another ridiculous build system.

The history of cake.coffee[1] suggests otherwise. It's been edited relatively few times since the initial checkin, mostly to make it compatible with node.js API changes, and sometimes to pare it down and simplify it. It was hardly touched at all in 2012. It is small and mindful of feature creep.

[1] https://github.com/jashkenas/coffee-script/commits/master/sr...

It appears that running `cake` doesn't check to see if there have been changes since the previous build. I wouldn't use a build system that didn't at least have this essential feature.

Compiling a CoffeeScript project is so quick that it would only add complexity without benefit.

>Hell no. They'll add features. So the cake of 2019 will, assuming a still-robust coffeescript community, look a lot more like rake or ant or scons or cmake. It won't be tiny. It won't be easy to read. It will be yet another ridiculous build system.

Which you will be free not to use. Along with not using Coffeescript.

Whoa there buddy, no need to stress. Just don't use it.

The only reason why `cake` exists is because at the time that CoffeeScript was first released, there wasn't a "standard" JavaScript build tool, and we wanted the "coffee-script" project to have as few dependencies as possible. Adding a simple way to expose functions to the command line made it possible for CoffeeScript to build itself, without relying on "make" (Windows), "jake" (very rare), or "rake" (a Ruby dependency).

Regarding your comment below -- it's definitely not going to grow. All it does is expose functions to the command-line. See a litany of "closed wontfix" tickets if you don't believe me ;)

Also -- and perhaps mainly -- releasing "coffee" and "cake" binaries together was too cute to resist.

Cake is a nice little tool. It could be detached from CoffeeScript and turned into a separate module, but it isn't hurting anyone.

When you're writing a node.js or browser project it's good to write build scripts in a language not too far from the main one, and it has the advantage of being able to use the whole node.js module ecosystem.

Take a look at this build script: https://github.com/ryejs/rye/blob/master/Cakefile#L52-L79 using flour[1]. I don't think you can get more succinct than that with any other build system, and it's blazing fast thanks to asynchronous I/O.

[1] http://github.com/ricardobeat/cake-flour

Somebody pissed on your cornflakes?

>The world doesn't need another build system.

Oh, but it does. Maybe not this one, but it sure needs a new build system.

To: JAshkenas, JWalton

From: The interwebs

Thank you for this! One of the biggest justifications for avoiding Coffee-Script has been the difficulty in debugging the translated code since there is (no longer) a 1-1 line mapping. This is now a thing of the past!

It took me all of 5 minutes to understand the new API for sourcemapping add support to Plunker. For those who are curious: https://github.com/filearts/plunker_run/commit/33eb3c5049b3e...

To me, this is the sign of a simple, but powerful API addition. Well done guys.

If you want an example of stepping through a sourcemapped coffee-script file, try adding a breakpoint to `app.coffee` on: http://beta.plnkr.co/edit/e5iLyQ?p=preview

where/how do we add the breakpoint? plunker looks awesome btw.

For anyone wondering (since it's such a new thing that not a lot of people know much about it): Source maps are currently only supported in Chrome, but it's also implemented in recent WebKit nightlies and Firefox is actively working on support. In order to use source maps in Chrome, open the options panel on the dev tools and make sure the "Source maps" option is enabled.

Right. As far as I know, they currently work in Chrome, in Node.js (with a library), in Webkit nightlies, and are getting close-ish in Firefox nightlies: http://fitzgeraldnick.com/weblog/45/

If you have Visual Studio, they have source map debugging for TypeScript working. You can do CoffeeScript dev in Visual Studio [1], but I have no idea if source maps work with that.

[1] http://visualstudiogallery.msdn.microsoft.com/2b96d16a-c986-...

It's supported in WebKit nightly too.

Thanks for that! Added to my comment. I meant to mention WebKit initially, but I got so focused on double-checking that my Firefox information was current that I just stopped afterward.

Watch out when updating to this. There are still some issues being resolved.

See:

https://github.com/jashkenas/coffee-script/pull/2751

https://github.com/jashkenas/coffee-script/issues/2765

https://github.com/jashkenas/coffee-script/issues/

If you've downloaded a prior version of version 1.6, you'll have to remove it from your `node_modules` folder and do an `npm cache clean` before reinstalling, as the version number is the same.

I've just pushed out a 1.6.1 update, trying to address these. If you're having any trouble with it, give 1.6.1 a try -- and if you're still having trouble, let me know.

Fixing one version with exactly same other is just wrong, why do they do that?

For someone who is new to Javascript (and programming in general), how do you know when it'a ok to move on to coffeescript? (I started with ruby and I like how coffeescript has similar syntax)

Although it is a great idea to learn javascript first, you can move to Coffeescript at any time. Coffeescript compiles to javascript.

Agreed. CoffeeScript is a leaky abstraction of JS; the underlying paradigm of JS still peeks out even though it's papered over (see the fat arrow =>).

Once you have a grasp of JS (and the things you might not like about it), you can then move to CS. When something looks a bit off in CS, you'll probably be able to translate why it is that way due to the JS underpinning.

Intentionally "leaky" ;) Martin Fowler has written a good post about how and why this is desirable:

http://martinfowler.com/bliki/TransparentCompilation.html

Probably right now. But that's a good question. As you've already seen, the documentation on http://coffeescript.org is phenomenal.

As a dev with maybe 1.5 years of JS experience, I've learned coffeescript in a week. I still don't have the coding style that my code reviewers want, but I'm writing functional code.

The biggest hurdle I've found is getting an auto-compiler for coffeescript. You don't want to do it manually:

    coffee -c media/js/page.js media/js/page.coffee

everytime you want to recompile your code. But there are tools for that! https://github.com/gruntjs/grunt-contrib-coffee

Was:

    coffee --watch

... not working well enough for you? For fancier build processes, you certainly might want to use a fancier build tool.

I have not had great luck mixing coffee --watch and gvfs for either FTP or WebDAV. An ugly, but effective solution is to configure your editor to compile on save. The most annoying part of that is when you switch to a project with a different build process, and you have to either reconfigure your editor, or deal with extraneous .js files being output.

For a minimal compile-on-save, you can just use: coffee -wc media/js/page.js media/js/page.coffee

It's not suitable for large projects, but it is good enough for single file compilation.

See here for more options: http://coffeescript.org/#usage

Give it a directory instead of a file and it will automatically compile any .coffee files in that tree.

That's a good point!

You can also ask yourself what step of learning you're at. Do you just want to build stuff? Then you can probably jump to coffeescript right away (especially with the new Source Maps feature). Do you want to get more in-depth knowledge of popular programming languages? Then stick with JS; learn how it handles types, how it handles functions, what the prototype chain is, how exceptions are thrown, etc. Maybe even read JavaScript: The Good Parts.

People build amazing sites in both languages... so you can't go wrong... it's just a matter of what you want to learn on the way. Good luck!

I think it could work well to start with CoffeeScript -- that is, to learn JavaScript by first learning CoffeeScript. For the real world you must understand native JavaScript, of course, but that could come incrementally. I don't actually know anyone who's done this, however.

Early in my Javascript career, I read "Javascript: the good parts", and started with Coffeescript very early. And I very often would look at the Javascript that Coffeescript was generating for me. I was pleased to find that Coffeescript automates a lot of the things that the book recommends. Totally worth doing early, in my mind, especially if you're interested in Coffeescript.

Started the same exact way

Don't consider learning a language like CoffeeScript or ClojureScript until you thoroughly understand JavaScript. I think it's much easier for a beginner to learn JavaScript APIs (both built-in and third-party), which you'll need, from JavaScript examples without having to translate them to another language in the process.

Also, I'm not sure you can use these other languages' features judiciously without understanding their reasons for doing things a certain way. You will need to know how `this' and `prototype' are used and things of that nature, then you can decide if you find the abstractions and overhead of compile-to-JS languages useful.

CoffeeScript implements a classical OO system: http://www.crockford.com/javascript/inheritance.html

Since I've programmed JS before CS was created, I've long been resigned that I'd have to understand and follow the idioms of both languages. But using CS is so much sweeter to read and write that I end up being lulled into thinking that I'm writing Ruby. I can't tell if my brain is taxed more at having to switch between Ruby and regular JS, or if it's more tiring to constantly remind myself "this is not Ruby. This is not Ruby. This is not Ruby" while writing long stretches of CS :)

But I've only dabbled with CS so I'm sure like with anything, practice reduces this mental fatigue. I am bummed that CS went to camelcase, but the justification back then was a good one

Spend a weekend building a tiny project with CS. Or use it to add a small feature to a project you already have.

You have to constantly be on the lookout for new tools that will give you new capabilities or make it easier for you to do the things you already do. So you should be willing to try something different like CS -- recognizing that it's a learning experience and it might not work out.

It's fine if you decide that CS isn't the best, and you want to stick to plain JS. Not every tool works well for every person. Sometimes everyone raves about the goodness of technology X, you try it and agree. Other times, you try it and hate it.

Sometimes you come back months or years later to a technology that gave you bad experiences, and due to changes in both you and the technology, you're pleasantly surprised. Or a long-proven technology that you've been using for years has slowly but surely been surpassed by something else, and is now nearly obsolete.

So it's not guaranteed that CS right now will work out for you, but you don't know until you try. And even if it doesn't, you should keep it in the back of your mind and take another look in a few months or years.

@jashkenas: with the release of this surprise, 'skunkworks' feature, what do you see as the future for Coffee-Script-Redux? Does the project remain relevant despite the recent activity in the original Coffee-Script project?

See my reply elsewhere in this thread: http://news.ycombinator.com/item?id=5320849

Thanks.

Good to know!

IIRC, this is one of the big reasons behind CoffeeScriptRedux. In fact, I have been following development of it closely and he's been working hard. I know he's contributed lots to the standard CoffeeScript codebase.

Does this deter him from completing that project? If not, what big features does Redux plan to offer that regular CoffeeScript does not? Using pegjs instead of jison?

You'll have to get Michael to answer that question, but to clear the air a bit -- it's very nice to have two versions of the compiler that don't share a common ancestry (Redux is a complete rewrite).

We may merge the Redux version in and bless it as the "official" compiler some day, when it matches feature parity, and if the codebase ends up cleaner than the original (both very likely things to happen). Even in the worst case scenario, where no merge happens, we all benefit, both for learning, new features, and shared fixes for bugs, from having two independent compatible implementations of the language.

Everything Jeremy said. And my compiler isn't far away from being polished enough for me to consider it ready to be labelled 2.0. Check out the 2.0 roadmap: https://github.com/michaelficarra/CoffeeScriptRedux/wiki/Roa...

95% of the language features were supported during my funding period. Since then, it's nearly reached 100% feature parity, and the tooling/interfaces have been much improved. The code is a lot cleaner, a lot smaller, more modular, more extensible, and uses standard IRs.

If you want to try it out, see the online editor here: http://michaelficarra.github.com/CoffeeScriptRedux/ (shameless plug: it was built using my new browser bundler with full minified-JS to CoffeeScipt source map support: https://github.com/michaelficarra/commonjs-everywhere)

For anyone curious about the compiler implementation process, see this recent slide deck from my MLOC.js talk: https://speakerdeck.com/michaelficarra/an-analysis-of-the-re...

I will say I very much like Redux and have used it for dumping AST nodes. I recently became interested in a project where I wanted to hack on and extend the grammar. I found this difficult in Redux, Coco (and friends), and couldn't use CoffeeScript because of lack of source map support previously.

I think a huge benefit for Redux will be making the grammar very clean and extensible. I know it's on your roadmap to CS-ify it.

Edit: Oh, and if you're curious, I wanted to play around w/ translating the CS AST to TypeScript AST, but I'd obviously need to add more typing/declaration syntax to the grammar.

I know I speak for many others when I say I have been waiting for this for a long time.

This is fantastic, thanks so much for the hard work :)

Congratulations on all this hard work. Source maps will CS an even more appealing alternative to plain Javascript and make my life as a developer better.

Thanks to all parties involved in producing this release.

So is there a way to use the source maps with node.js stacktraces?

Specifically, I tried this test.coffee:

  throw new Error("Test")

Now running it with

  coffee test.coffee

still reports the wrong line number in the stack trace.

There's supposedly node-source-map-support (https://github.com/evanw/node-source-map-support), but even installing that and adding "require 'source-map-support'" won't help.

Ok, you'll have to run it through the compiler first with the -m option:

test.coffee:

  require 'source-map-support'
  throw new Error("Test")

Now do:

  npm install source-map-support
  coffee -c -m test.coffee
  node test.js

This gets you the correct line numbers.

The hard part for me to understand is that I've got way more than just a single file. I've got hundreds of coffee script files for a rather complex nodejs/express app.

I start it up with something like this:

  nodemon -w . lib/start/web.coffee

  or in production:

  coffee lib/start/web.coffee

That web.coffee file then require's a chain of files.

If I try to compile the source maps for all of my files first, using something like this:

  mkdir .compile
  coffee -m --output .compile --compile ./

In the .compile folder, there is a few oddly named subdirectories (d, b, rands, sc) with the compiled .js files in there and the respective .map files. This seems to totally break my require chain.

Since I don't normally pre-compile all my coffee script files, I just run them directly using nodemon or coffee, how can I work the maps into my dev process?

Does it somehow require running the code to generate the maps? I'm asking because when I add the "-m" to my coffee compile line I get:

    TypeError: In test.coffee, Cannot call method 'indexOf' of undefined

The line in question calling _.indexOf() from the underscore library... It compiles just fine without the -m option.

No.

    coffee --compile --map file.coffee

Should produce a "file.js" and a "file.map".

Hmmm:

    $ coffee --version
    CoffeeScript version 1.6.1
    $ coffee --compile static/test.coffee
    $ coffee --compile --map static/test.coffee
    TypeError: In static/test.coffee, Cannot call method 'indexOf' of undefined
        at Object.count (~/.npm/lib/node_modules/coffee-script/lib/coffee-script/helpers.js:33:29)
        at Object.compile (~/.npm/lib/node_modules/coffee-script/lib/coffee-script/coffee-script.js:72:30)
        at ~/.npm/lib/node_modules/coffee-script/lib/coffee-script/command.js:171:33
        at ~/.npm/lib/node_modules/coffee-script/lib/coffee-script/command.js:141:18
        at [object Object].<anonymous> (fs.js:123:5)
        at [object Object].emit (events.js:64:17)
        at Object.oncomplete (fs.js:1181:12)

(Paths were full path names, I replaced my $HOME with ~ in the output for clarity and some security through obscurity)

Not being able to use getters, setters and yield[1] is a big turnoff for me. I want to move towards ES6 as quickly as possible.

[1] https://github.com/jashkenas/coffee-script/wiki/FAQ

What happened to CoffeeScript 2 that was funded over Kickstarter. Wasn't this supposed to bring source maps etc to CoffeeScript?

Absolutely awesome! Am working on support for Errbit, so we can finally have usable JavaScript exception reporting.

Anyone have a good example of using --map with --join?

In TypeScript it works out-of-the-box, plus TypeScript compiles to idiomatic JavaScript and what you write is much closer to what you get, and the transition is much easier understandable.

How is any of this relevant?

I am just pointing out at an alternative.

Reply on news.ycombinator.com