source maps update is good
And finally we would get better stack traces in mocha.
I see, I see. While I have the ability to make releases if there was an emergency, I've never been able to build the documentation and otherwise prepare a clean release. Let's just wait until Jeremy gets the time to make a release. In my projects, I have a make target to do this so the process is entirely automated: https://github.com/michaelficarra/commonjs-everywhere/blob/f9201f47321424bd353376ea4bb23ae145aff8b8/Makefile#L20-L40
it would be great to document the clean release process also
@lydell re: mocha; Our of curiosity, with this release does Mocha work out of the box? Or do you have to hack/change the behavior of Mocha for the maps to work properly?
Just use the --compilers option as before, and it will work out of the box!
And finally no more '-p' folders on windows (#2027).
Working on it ... if anyone wants to pitch in -- hop on IRC, and let's get to it.
Alright folks -- getting close to being ready for a 1.7.0 release. Please take a minute and bang on master if you can, let me know if you have any outstanding problems.
There are also a couple of open tickets I'd prefer to get cleared up before releasing, to wit:
#3139, #3087, #3059, #3008, #2919 ... and most importantly, although if it doesn't make it, them's the breaks: #2779.
If you have any thoughts on solving those, they'd be much appreciated.
We should improve #3054 (the fix for #2323) before the next release. I don't want to get that one wrong in a release.
@michaelficarra -- #3054 didn't get merged. I did this instead:
... what exactly should be changed?
You can't "require coffee-script/extensions" as you claim. You'd need a file in the root, like how I have /register.js in CSR to allow users to require coffee-script-redux/register. Also, can we make the names consistent? I would prefer register, since CSR users have been using that for a while, and it's more descriptive IMO.
@jashkenas @michaelficarra Can we make it so that if a script is loaded via the coffee executable, the handler is automatically registered? Since the user intention is already clear that he/she is gonna be running and requir-ing coffee-script modules from that point.
Here's a very simple test code: https://gist.github.com/chakrit/219bf9153d7cd3014af6. Running coffee main.coffee now breaks with coffee from current master. And yeah, require 'coffee-script/extensions' does not work.
I totally understand the rationale behind splitting out the handler registration but IMO If the user is using the coffee executable directly, then the handler should be auto-registered since the intention and expectation is that we're going to be running many coffee-script modules anyway.
Otherwise many standalone scripts (test runners, self-runnable test files with shebangs, automation scripts, entrypoints, whatnots) will be broken as soon as 1.6.4 lands.
And fixing them is not easy, since you have to figure out which file may or may not be run from the command line and modify each file to invoke the handler registration (could be a lot of files for large projects, which use tap, for example)
p.s. or should I move my comment to #2323 instead?
Two quick pairs of cents:
register is also the name that Streamline.js uses, and indeed via a register.js file at the root.
I agree that the coffee binary should register the extensions; Streamline does this as well.
Edit: I want to say I'm really thrilled to see all the great features and fixes that have been coming. Keep up the fantastic work, everyone. Looking forward to this release!
Agreed with both of you. That is how CSR behaves:
$ echo console.dir Object.keys require.extensions | bin/coffee -e
[ '.js', '.json', '.node', '.coffee', '.litcoffee' ]
Any status on this update? I'd love to give it a shot.
fix auto and manual require.extensions registration; ref #3141
You can now `require('coffee-script/register')` to manually register,
and the compiler auto-registers when directly running a coffee file.
@chakrit: @aseemk: Check out #3279.
@michaelficarra Just tried master and seems it is fixed now. 👍
Does this new registration thing mean that we should run mocha --compilers coffee:coffee-script/register instead of mocha --compilers coffee:coffee-script?
mocha --compilers coffee:coffee-script/register
mocha --compilers coffee:coffee-script
@lydell: Yes. Also, if you want to require coffee files from your tests, I believe you need to pass -r coffee-script/register. It's been a while since I've played with my default mocha settings, though.
@michaelficarra @lydell: you don't need to pass --require (-r) if you've already passed --compilers. No biggie tho.
Can you just ship ANYTHING? I'm pretty tired of dealing with coffeescript issues that were fixed in master 4 months ago
I'm okay with shipping what's on master right now.
I'd have liked to get generators in, but it's probably best to do it now.
Christmas release? +1
I really wish we could get generators (#3240), new operators (#2887), expansion (#3268) and chaining in in one go (syntax related changes) but latest is getting really behind, so a release now wouldn't hurt.
It sounds like generators aren't that far away. That said, you can make a point release just for generators, as soon as it's ready.
No chaining syntax and gen support till 2014? Santa gave me socks this christmas.
A Christmas release it shall be (let's hope).
CoffeeScript was originally released as a festive holiday gift: https://news.ycombinator.com/item?id=1014080 ... so it'll make for a nice anniversary.
I remember rushing to get a few fixes in before the 1.0 Christmas release, also.
Regular releases at known time points are considered good for any project.
And having some traditions is great.
Today's not looking likely, I'm afraid, folks — unless someone else wants to do the paperwork, and have me push the button. Cousins in town.
Take your time.
Proper return codes when using --nodejs option - important when using in CI-Servers
Is there an estimated release date for 1.6.4 yet?
Let's move our discussion to more corresponding issue.
@paulmillr That's a joke, right? :)
More like a "I've had enough". Original post still stands, though: reopening.
Perhaps we should open an "Reduce the amount of paper-work needed to publish a release" issue and an "Formulate a release policy, so that bigger changes don’t block simple bug fixes" issue. But obviously it is not as easy as I might make it sound ;)
@lydell: Yes, we've been trying to do that for a while. Recently, #3198 made a big step in that direction, moving us away from ruby/ultraviolet for building the docs. Now we can finally automate the release process, or at least get it documented so any of the maintainers can confiedently cut a release. In some of my projects, I have completely automated releases.
This probably won't help out people waiting on a new release much, but I pushed coffee-script-nightly to npm, along with generators (--> and yield from) and two other PRs (pushing master itself would be less useful). See README. If someone thinks this a particularly bad idea, let me know.
but I pushed coffee-script-nightly to npm
but I pushed coffee-script-nightly to npm
I think that's a fantastic idea. Although having coffee-script-master on npm would arguably be even more useful.
I love the idea of coffee-script-nightly, where we can release frequently, without all the documentation overhead, and get an idea of issues before we make a stable release.
coffee-script-master kind of already exists "on npm": npm install jashkenas/coffee-script
npm install jashkenas/coffee-script
npm install jashkenas/coffee-script
I didn't know about that feature. Super useful. Thanks.
npm install jashkenas/coffee-script should be added to the dox, that is cool.
@jashkenas @michaelficarra I think coffee-script-nightly is a bad idea (ironic). I hoped this would nudge Jeremy a bit to make the release. I would be more than happy to help out in any way I can, we really need to release at least some of the bug fixes.
We certainly do. I'm happy to push the button if someone wants to write up the changelog, and edit the docs to match.
@jashkenas I'll look into it, but could you give your opinion on operators (#2887), I think that's well settled; and expansion (#3268), should get either closed or accepted.
Moving to "Release 1.7.0"...