Skip to content

release 1.6.4 #3141

Closed
paulmillr opened this Issue Aug 28, 2013 · 52 comments
@paulmillr

source maps update is good

@lydell
Collaborator
lydell commented Aug 29, 2013

And finally we would get better stack traces in mocha.

@michaelficarra
Collaborator

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

@paulmillr

it would be great to document the clean release process also

@rwilcox
rwilcox commented Sep 4, 2013

👍

@leeola
leeola commented Sep 16, 2013

@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?

@lydell
Collaborator
lydell commented Sep 17, 2013

Just use the --compilers option as before, and it will work out of the box!

@robi-wan

+1
And finally no more '-p' folders on windows (#2027).

@jashkenas
Owner

Working on it ... if anyone wants to pitch in -- hop on IRC, and let's get to it.

@jashkenas
Owner

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.

@michaelficarra
Collaborator

We should improve #3054 (the fix for #2323) before the next release. I don't want to get that one wrong in a release.

@jashkenas
Owner

@michaelficarra -- #3054 didn't get merged. I did this instead:

b173a37

... what exactly should be changed?

@michaelficarra
Collaborator

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.

@chakrit
chakrit commented Oct 30, 2013

@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?

@aseemk
aseemk commented Nov 10, 2013

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!

@michaelficarra
Collaborator

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' ]
@Quazie
Quazie commented Dec 3, 2013

Any status on this update? I'd love to give it a shot.

@michaelficarra michaelficarra added a commit to michaelficarra/coffee-script that referenced this issue Dec 8, 2013
@michaelficarra michaelficarra 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.
ba4743c
@michaelficarra
Collaborator

@chakrit: @aseemk: Check out #3279.

@chakrit
chakrit commented Dec 9, 2013

@michaelficarra Just tried master and seems it is fixed now. 👍

@lydell
Collaborator
lydell commented Dec 9, 2013

Does this new registration thing mean that we should run mocha --compilers coffee:coffee-script/register instead of mocha --compilers coffee:coffee-script?

@michaelficarra
Collaborator

@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.

@aseemk
aseemk commented Dec 9, 2013

@michaelficarra @lydell: you don't need to pass --require (-r) if you've already passed --compilers. No biggie tho.

@layerssss layerssss referenced this issue in maxtaco/coffee-script Dec 14, 2013
Closed

`require` extensien hook broken in 1.6.3-h #100

@paulmillr

@jashkenas @michaelficarra

Can you just ship ANYTHING? I'm pretty tired of dealing with coffeescript issues that were fixed in master 4 months ago

@michaelficarra
Collaborator

I'm okay with shipping what's on master right now.

@nfour
nfour commented Dec 23, 2013

+1

@vendethiel
Collaborator

I'd have liked to get generators in, but it's probably best to do it now.

@xixixao
xixixao commented Dec 24, 2013

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.

@bjmiller

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.

@nfour
nfour commented Dec 24, 2013

No chaining syntax and gen support till 2014? Santa gave me socks this christmas.

@jashkenas
Owner

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.

@michaelficarra
Collaborator

I remember rushing to get a few fixes in before the 1.0 Christmas release, also.

@paulvi
paulvi commented Dec 24, 2013

Regular releases at known time points are considered good for any project.
And having some traditions is great.

@jashkenas
Owner

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.

@dashed dashed referenced this issue in contra/gulp-coffee Jan 5, 2014
Closed

Support Source Maps #1

@dashed
dashed commented Jan 5, 2014

Take your time.

@robi-wan
robi-wan commented Jan 9, 2014

+1
Proper return codes when using --nodejs option - important when using in CI-Servers
(c5120c7)

@RobLoach RobLoach referenced this issue in Hypercubed/docpad-plugin-raw Jan 15, 2014
Closed

Remove out directory #8

@pmgration

Is there an estimated release date for 1.6.4 yet?

@dashed
dashed commented Jan 17, 2014

@pmgration 2015.

@paulmillr paulmillr closed this Jan 17, 2014
@paulmillr

Let's move our discussion to more corresponding issue.

@xixixao
xixixao commented Jan 19, 2014

@paulmillr That's a joke, right? :)

@vendethiel
Collaborator

More like a "I've had enough". Original post still stands, though: reopening.

@vendethiel vendethiel reopened this Jan 19, 2014
@lydell
Collaborator
lydell commented Jan 20, 2014

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 ;)

@michaelficarra
Collaborator

@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.

@xixixao
xixixao commented Jan 21, 2014

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.

@jashkenas
Owner

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.

@michaelficarra
Collaborator

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.

@lydell
Collaborator
lydell commented Jan 21, 2014

coffee-script-master kind of already exists "on npm": npm install jashkenas/coffee-script

@jashkenas
Owner

npm install jashkenas/coffee-script

I didn't know about that feature. Super useful. Thanks.

@nfour
nfour commented Jan 21, 2014

npm install jashkenas/coffee-script should be added to the dox, that is cool.

@xixixao
xixixao commented Jan 23, 2014

@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.

@jashkenas
Owner

We certainly do. I'm happy to push the button if someone wants to write up the changelog, and edit the docs to match.

@xixixao
xixixao commented Jan 23, 2014

@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.

@jashkenas
Owner

Moving to "Release 1.7.0"...

@jashkenas jashkenas closed this Jan 27, 2014
@rlidwka rlidwka referenced this issue in nodeca/js-yaml Apr 17, 2014
Closed

bring back require.extensions #119

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.