CS2 Discussion: Project: Progress as of May 2017: 2.0.0-beta2!

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-17 02:31

Hey everyone,

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

Since the last update, as of 2017-05-16 the following has been merged into the jashkenas/coffeescript 2 branch and released in 2.0.0-beta2:

• Polyfills were removed, thanks to @GeoffreyBooth and @connec.
• Fat arrow class methods are no longer supported, thanks to @connec.
• The CoffeeScript module can now be required in builds intended for non-Node environments such as those created by Webpack or Browserify, thanks to @akfish.
• Literate CoffeeScript parses Markdown better and now without dependencies, thanks to @GeoffreyBooth.
• The coffee command prefers the locally-installed version of CoffeeScript over the global one, allowing you to have separate versions installed in a project versus globally, thanks to @GeoffreyBooth.
• Bugfixes for chained functions relating to ternaries and implicit objects, thanks to @xixixao.
• return and export default can now accept implicit objects, thanks to @GeoffreyBooth.
• JavaScript keywords used as properties no longer require quoting, thanks to @GeoffreyBooth.
• The browser compiler is now compiled with Babili, making it safe to run in all common browsers, thanks to @GeoffreyBooth.
• Various other bugs were fixed, thanks to @helixbass, @xixixao, @connec and @GeoffreyBooth.

I’ve moved the full honor roll to a wiki page.

I went through all 300+ open issues and whittled them down. Over a hundred were closeable thanks to the updates of CS2 🎉 and any proposals more than a year old I simply closed for lack of interest. In one PR I managed to close all ten outstanding issues related to documentation. Many other issues had simply been overlooked, and led to several quick one-commit PRs for fixing simple bugs. Many more concerned using the coffee command to run scripts and things not working as expected, which I closed because I think expecting coffee to be as full-featured as the node command is too much to ask of us. Issues like those, that I consider to be out of scope but could be fixed if someone wants to take the time, I tagged as patches welcome!.

This has reduced our open issues count to 68 at the time of writing, which was a worthy effort IMO because the more manageable we can keep that number the more likely bugs are to get fixed (and the less abandoned the project looks to others). I also prefixed each issue with common keywords like “Invalid JS” or “Lexer” so that bugfixers can search for related issues more easily. In particular I used “Lexer,” “Grammar,” “Nodes” and similar because those relate to lexer.coffee, grammar.coffee etc. in the CoffeeScript codebase, so if you’re fixing one bug in one of those files you should look for any other open bugs that might be nearby. Once you have an understanding of how a file works, you’re in a good position to be able to fix multiple bugs in it.

I also tagged a handful of issues priority. If people can help fix these, your efforts would be greatly appreciated!

And please try 2.0.0-beta2 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!

[coffeescriptbot]

From @ryansolid on 2017-05-18 07:54

Congrats on another release. It really seems to be getting close. I've been trying out each new version evaluating the changes in my personal projects. Also since I am technical lead at a company where we are heavily invested in Coffeescript using it exclusively on all our ongoing servers, web applications, and mobile apps in production for the past 5 years, including 120+ shared modules.

To be fair I've considered myself pretty lucky up til now. However, the compiler error on bound fat arrow class methods is going to be felt as its widespread and not backwards compatible. This is the first change that will require maintaining multiple versions through the course of migrating making it no longer trivial. On the positive I don't need to concerned(watching like a hawk) for other breaking changes anymore as, for example, if it was decided the spread operator should only work in the ES direction it wouldn't be any more disruptive than this.

I understand the necessity of these changes and if anything I think this is actually freeing in it's gotten to a point where maybe it's ok to be less concerned with breaking existing coffeescript if it's better for the language. Just food for thought.

Edit: Above was my initial reaction. Having converted a simple/trivial project I have a new perspective: coffeescript6/discuss#84

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-18 15:49

@ryansolid thanks. Yeah, it always sucks to remove a feature, and removing this one doesn’t improve the language. It was basically done because fat arrow class methods don’t exist in ES, and any invisible machinations we could do to support them (the way we still support executable class bodies) led to varying differences from the 1.x behavior, such that there would be subtle bugs that would be difficult to troubleshoot. It seemed safer to remove them entirely and throw an error, rather than having your code execute in unexpected ways.

See http://coffeescript.org/v2/#breaking-changes-classes. It advises refactoring to put such methods in the constructor:

class B extends A
  method: =>  # Throws a compiler error
  
  constructor: ->
    super()
    @method = =>  # This works

[coffeescriptbot]

From @rattrayalex on 2017-05-18 16:10

Just wanna pop in and say that both these announcements and their contents are amazing. Applauding from the peanut gallery, thanks so much for all your incredible, hard work @GeoffreyBooth !

[coffeescriptbot]

From @ryansolid on 2017-05-18 17:08

Yeah. If you move all the code inside the constructor it should work. Actually does that support inheritance like the following?

class B extends A
  constructor: ->
    super()
    @method = =>  super(arguments...)

Besides being really awkward having to refactor thousands of classes (and mean every single one of them and pretty much every method), I do wish there was a better solution since to me this actually changes what Coffeescript is. It's more than a syntax change. Basically it's up to the caller instead of the declarer to bind this in general. If I had written back when @rattrayalex first posted about what Coffeescript and what should/couldn't change etc, before the current leadership really got in full swing I would have said:

1. Whitespace matters
2. Variables declarations are not necessary
3. This binding is part of the object/class definition rather than a consideration of the caller
4. All expressions implicitly return

Personally for me it was my 2nd most appealing Coffeescript feature. Obviously the whole list is pretty breaking. But out of these this affects projects most on a macro level (besides obviously white space being a requirement to compile any of it). Especially conceptually, I've been training developers for years not having to worry about the this context at call time. Variable declarations/returns are contained with the routines that leverage them and are localized. Wherease syntax changes often will keep semantic meaning.

I will have to kill the pattern eventually or be forced to forever have classes completely nested in their constructors. Right now picture trying to sell a new developer on Coffeescript and you show them that. Obviously EcmaScript is no better in that regard, but I suspect I will hit several more gotchas as I explore this change since all the existing code assumes it works a certain way. I will continue for the time being evaluating this, but I do fear this will be a non-starter. The effort to update and refactor over time would actually be more complex than introducing ES6 since I'm not sure it's possible to be running multiple coffeescripts at the same time and if the effort to migrate is sufficiently large enough that it couldn't be done over a short enough period to realistically manage the code the split. This is no longer a find/replace or a localized one over in every file. It will require considerations spanning multiple modules.

[coffeescriptbot]

From @mrmowgli on 2017-05-18 17:19

Yes! I have to give lots of kudos to @GeoffreyBooth for stepping up to drive CoffeeScript forward!

I personally appreciate the constant focus and follow through. It takes a lot of patience to make everything happen while still being open to (and championing) useful changes.

I always find the status updates super helpful!

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-18 17:27

Thanks @rattrayalex and @mrmowgli 😄 I’m a technical lead/project manager in my day job, and that feels a lot like this 😄

Speaking of which, @ryansolid I feel your pain. We should probably move this discussion to #84. If I could just ask one more general question here though, what percentage of your problematic bound class methods need to be bound, i.e. what percentage reference @ or this? I realize it would take some coding to answer precisely, but it would be illuminating to know the answer for a real-world substantial codebase such as yours. That would tell us how prevalent this problem is, and how much pain this breaking change is likely to cause for people.

Anyway I ask because obviously, if the method doesn’t reference this, you could change => to -> and it would work as is. If 90% of your methods do reference this, then that’s not much of a savings. But if only 10% do, then the refactoring challenge isn’t so steep.

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-18 18:28

I’m hoping that there might be only one more beta before we release 2.0.0. beta3 would be because there’s one more potential breaking change in the pipeline, for JSX support (see #4551 and #4553). The breaking change in that case is pretty minor, just that you would need spaces around < and > instead of code like i<j. And before this thread becomes a flame war about JSX, please use #4529 for discussing such matters as whether JSX should be supported at all or what the CoffeeScript version of its syntax should be.

I’m also considering trying to improve our support for comments, allowing block comments anywhere and preserving end-of-line comments. This would potentially also be a breaking change, although also minor, because the currently-preserved block comments might not be preserved in the same places in the new version as before. I could use some help on this (see #4541) if anyone is interested. In particular, I’m trying to figure out how to preserve extra properties attached to a token in lexer.coffee through the parser to nodes.coffee, the same way our location data (for source maps) is preserved now.

[coffeescriptbot]

From @objectkit on 2017-05-18 20:54

I'm probably opening a can of worms by asking this, but I mean well. From an aesthetics point of view, what are the chances of being able to omit : in the context of class methods at this time?

class Slim

    constructor (auto = no) ->
        if auto
            @init()

    init ->

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-18 20:56

@objectkit That would cause ambiguous syntax. init -> would become init(function () {});

[coffeescriptbot]

From @objectkit on 2017-05-18 20:57

Compilation issue. Got it. Thanks for the clarification!

You're doing a great job btw @GeoffreyBooth.

[coffeescriptbot]

From @GeoffreyBooth on 2017-06-30 18:06

Closed via coffeescript6/discuss#86