CS2 Discussion: Project: Progress as of April 2017: 2.0.0-beta1!

[GeoffreyBooth]

Hey everyone,

CoffeeScript 2.0.0-beta1 is released! Install it via: npm install coffeescript@next

Yes, coffeescript, not coffee-script. I hope to release the 2.x versions on coffee-script once we determine that it’s safe to do so. More on that here.

Since the last update and the 2.0.0-alpha1 release, as of 2017-04-14 the following has been merged into the jashkenas/coffeescript 2 branch:

• Destructuring is now output using ES2015 syntax, thanks to @connec and @GeoffreyBooth.
• Literate CoffeeScript now parses Markdown much better, thanks to @GeoffreyBooth.
• get and set keywords now throw an error, preserving the option of supporting them as keywords in the future; thanks to @GeoffreyBooth.
• The v2 docs discuss our design decisions regarding let/const and get/set, as well as address why CoffeeScript in an ES2015+ world, thanks to @mrmowgli and @GeoffreyBooth.
• Several lexing bugs and one parsing bug were fixed by @helixbass and @GeoffreyBooth.

As of February, we had accomplished:

• Classes, including idiomatic output for both the class and super keywords, thanks to @connec.
• Redesigned docs for v2, thanks to @GeoffreyBooth.
• Refactored Cake tasks adding watch modes to building the compiler, thanks to @GeoffreyBooth.

As of December, we had accomplished:

• Tagged template literals, thanks to @greghuc.
• Interpolated strings are now output as template literals (ES backtick syntax), thanks to @greghuc.
• Triple-backtick operator and escaped backticks in embedded JavaScript, thanks to @GeoffreyBooth.
• The browser tests work again, thanks to @GeoffreyBooth.

And as of November, we had accomplished:

• Async/await, thanks to @GabrielRatener.
• Arrow functions, function default parameters and function rest parameters, thanks to @GeoffreyBooth.
• Splats in arrays and function calls are output using ES2015 syntax, thanks to @connec.
• Computed properties are output using ES2015 syntax, thanks to @connec.
• Octal and binary literals are output as-is, thanks to @JimPanic.
• CoffeeScript is stricter about whitespace thanks to @eelco, and Literate CoffeeScript now understands Markdown thanks to @billymoon.
• Support for ES2015 for…of is implemented, thanks to @atg.
• Bugs were fixed by @alangpierce, @shreeve, @JimPanic, @GeoffreyBooth and others. Also thanks for feedback from @lydell and @jashkenas.

---

This wraps up all the features we had planned to be in scope for CoffeeScript 2! Hence this is the first beta release. The plan from here to 2.0.0 is to fix any bugs that people find, and release 2.0.0 out of beta as soon as we feel confident that it is stable.

That doesn’t mean development needs to stop! There’s still time for new features, both before and after 2.0.0 is released; though if your new feature is a breaking change, it should come before. Foremost among the upcoming features in progress is destructuring object spreads.

Please try 2.0.0-beta1 in your projects! And let us know if you encounter any issues, after first reviewing the breaking changes. If you think there’s a bug, please open an issue with “[CS2]“ in the title. Please don’t comment bug reports on this thread. Thanks!

[balupton]

Congratulations to everyone involved on this!

How is linting and other ecosysten projects coming along on fhe CoffeeScript 2 front?

[GeoffreyBooth]

CoffeeLint has a PR in progress to support CS2, but it could use some help.

[mikeyhew]

Nice work @GeoffreyBooth et al! I'm already using the new beta in Rails with Webpacker, and it's just wonderful.

[GeoffreyBooth]

@mikeyhew Thanks for the feedback! Anyone else using this on real projects? I’m feeling beta1 is probably stable enough to release as 2.0.0?

Can anyone think of any additional breaking changes we want to slip in before leaving beta?

[mikeyhew]

I have an idea about reserving the word mixin... the new JS Classes lend themselves to a nice pattern for mixins, described here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Mix-ins. If CoffeeScript supported that pattern natively that would be pretty cool.

You would declare a mixin with mixin Foo, just like declaring a class except it compiles to a function that takes a class Base as an argument and returns a class extending Base. Then you could use them like so:

class Bar extends SomeBaseClass with Foo, Baz

which would compile to

class Bar extends Baz(Foo(SomeBaseClass)) {}
// order of mixins reversed, so that Foo occurs higher on the
// prototype chain, with Baz possibly overriding Foo methods

[mikeyhew]

Another really cool thing would be using ~ for postfix function calls, like @rattrayalex is doing for LightScript. To be able to add that at some point in the future without breaking backward compatibility, we'd have to disallow use of ~ as bitwise not. I really like that feature, but maybe it'd be better to just have it be a breaking change if/when it comes out - especially since I doubt ~ comes up much in CoffeeScript code. Or it could be an opt-in plugin?

Just thought I'd mention it.

[GeoffreyBooth]

@mikeyhew I think the place for proposals is as new issues in this repo. Want to post these ideas there? For whole-cloth new features, presumably we would create a syntax for them that isn’t a breaking change, like you were mentioning with ~.

Are there any other potential features on the horizon that pose a breaking-change threat? I’m thinking specifically of new or upcoming ES features that we might want to adopt, that would imply a certain syntax if we want to mirror the ES syntax.

[connec]

I'm loathe to bring it up... but we might want to have a plan for dealing with ES' class public fields Stage 2 proposal. The syntax that's currently under discussion conflicts with executable class bodies:

class A {
  own_property = 1
  own_method = function () {}
  own_bound_method = () => {}
}

Babel REPL

---

Compare this with the below, currently valid CoffeeScript code:

class A
  own_property = 1
  own_method = ->
  own_bound_method = =>

Try CoffeeScript

If we want to avoid breaking changes in the future it would make sense to have a plan for how to deal with these without breaking ECBs, or else let go of ECBs and patch them out of 2.

[connec]

Another one to possibly have a plan for is decorators (even if the plan is to ignore them). These are also Stage 2.

[GeoffreyBooth]

@connec We could have a section in the docs specifically about executable class bodies, warning people that their output will likely change in the future. It looks like the CoffeeScript syntax won’t be changing, but we’ll eventually be outputting ES output for these things as ES catches up to us. That shouldn’t break things, assuming the features’ implementations are equivalent to what we’re doing now, and if that’s the case then it’s not actually a breaking change (just a, you know, change). But we could warn people that there might be slight differences, which would be breaking changes.

[mikeyhew]

@GeoffreyBooth understood. I opened #81 to talk about mixins. I still think that reserving mixin would go a long way, but maybe it's too late in the release process for that. It's up to you.

[GeoffreyBooth]

Do we need a new keyword? The ES proposal doesn’t use one. Say we released 2.0.0-beta1 as 2.0.0 now, and wanted to add mixins later. Couldn’t we add them, and it wouldn’t be a breaking change?

[mikeyhew]

@GeoffreyBooth I'm not aware of an ES proposal for mixins. Can you post a link in #81?

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4973