Skip to content
This repository has been archived by the owner. It is now read-only.

CS2 Discussion: Project: Progress as of February 2017: 2.0.0-alpha1! #71

Closed
GeoffreyBooth opened this issue Feb 22, 2017 · 45 comments
Closed
Labels

Comments

@GeoffreyBooth
Copy link
Collaborator

@GeoffreyBooth GeoffreyBooth commented Feb 22, 2017

Hey everyone,

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

You may notice that it’s not at coffee-script. The powers that be at NPM were kind enough to release the coffeescript package name to us. Since no one really spells CoffeeScript with a hyphen anymore, it seemed a better choice. It has both the old versions and 2.0.0-alpha1, and will be the home for future versions. coffee-script will stay 1.x-only, in case anyone installs coffee-script and expects a compiler that outputs ES3.

Since the last update, as of 2017-02-21 the following has been merged into the jashkenas/coffeescript 2 branch:

As of December, we had accomplished:

And as of November, we had accomplished:


There are still a handful of features yet to implement, including destructuring and getters/setters. Help with those is most welcome, but if you don’t have time for that, you could also help out by trying 2.0.0-alpha1 in your projects. Please review the breaking changes first, and 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!

@jiyinyiyong
Copy link

@jiyinyiyong jiyinyiyong commented Feb 22, 2017

Any clarification for npm info coffeescript?

     '1.12.4',
     '2.0.0-alpha1',
     '99.999.9999',
     '99.999.99999' ],
@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 22, 2017

The 99 versions are leftovers from the previous package, which was just a warning that you had misspelled CoffeeScript.

@jiyinyiyong
Copy link

@jiyinyiyong jiyinyiyong commented Feb 22, 2017

Will it affect 2.0.0? It's strange that npm does not pick the higher version which is 99.x.

@lydell
Copy link

@lydell lydell commented Feb 22, 2017

npm install foo is just a shorthand for npm install foo@latest. It is up to the publisher to decide what the latest tag should point to.

@nickdima
Copy link

@nickdima nickdima commented Feb 22, 2017

Great job everybody! I'm curious what new oportunities will CS2 bring around tooling (stuff like linting, auto-formatting, etc.) and how it could benefit from the babel & co. ecosystem.

@scottwarren
Copy link

@scottwarren scottwarren commented Feb 23, 2017

What are your guys thoughts on outputting something when people install coffee-script to let them know that the "latest" is a package name change, and now lives at coffeescript instead?

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 23, 2017

@scottwarren Maybe after 2.0.0 final is released, that's a thought.

@lydell
Copy link

@lydell lydell commented Feb 23, 2017

@nickdima Basically none. CS2 uses the same architecture as CS1.

@DomVinyard
Copy link

@DomVinyard DomVinyard commented Feb 24, 2017

awesome! well done guys, we're lucky to have you. Now, I guess I need to start a new project to test all this stuff out on! Hmmm... choices, choices... x

@YamiOdymel
Copy link

@YamiOdymel YamiOdymel commented Feb 24, 2017

I'm using CoffeeScript 2 with WebPack and Vue.js and it works great! (except for the spread operator)

@laurentpayot
Copy link

@laurentpayot laurentpayot commented Feb 24, 2017

To use CS2 with webpack I simply had to create a symbolic link from coffeescript to coffee-script in my node_modules folder. It's working fine. I see that @YamiOdymel already created an issue in coffee-loader: webpack-contrib/coffee-loader#27 😄

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 24, 2017

@YamiOdymel Thanks! As for the spread operator, that seems like something that should be implemented as part of destructuring (#69) which I’ve started a branch for if you’d like to take a crack at it . . . 😉

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 26, 2017

Has anyone tried CS2 on an existing project? What changes, if any, did you need to make to your code?

@joeldrapper
Copy link

@joeldrapper joeldrapper commented Feb 26, 2017

@GeoffreyBooth I was going to integrate it into an existing Rails app, but the coffee-script-source gem doesn’t have the alpha yet. I’d submit a PR, but it appears to be closed source?

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 26, 2017

@joeldrapper I don’t know anything about that gem. We probably won’t be submitting CoffeeScript to upstream packages like that one until 2.0.0 final is released. Could you perhaps install the gem and then manually replace the CoffeeScript lib folder inside it?

@JavascriptIsMagic
Copy link

@JavascriptIsMagic JavascriptIsMagic commented Feb 26, 2017

Yes! 2.0.0 is approaching! Thank you guys so much for giving coffeescript some much needed attention!

I switched to CS2 on a few react applications and only had a minor problem with the way things where declared in classes while extending React.Component but it has since been resolved and it all works fine with pretty much no changes to the code. I will point out that we use class very sparingly preferring pure functions, so that might be why we didn't run into more problems. It's been a very smooth transition from CS1 to CS2 for the most part.


I do have to point out that it's extremely unfortunate that CS2 is going to be published to a different package name instead of using version semantics. That just means that there are 5,178 packages that may have been compatible with CS2, including IDE things like linters and such, but if you want to use them in your own CS2 you need to use a workaround like symlinking to coffee-script folder, or by bypassing npm using npm install coffee-script@jashkenas/coffeescript#2

This seems like a huge barrier to entry.


Anyways, again, thank you guys so much! I love seeing coffeescript developing again!

@bd82
Copy link

@bd82 bd82 commented Feb 26, 2017

I do have to point out that it's extremely unfortunate that CS2 is going to be published to a different package name instead of using version semantics.

This also means that dependency management services like:

Will not be able to recognize that there is a new version of CoffeeScript out.
So it would take longer for some users to even recognize that a new version is out.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 27, 2017

The coffeescript NPM package has the old versions too. It's more a renaming of the package than a “new” package.

The thought behind not releasing 2 on the coffee-script package was that we're trying to avoid breaking those downstream tools that probably expect a CoffeeScript compiler that runs as ES3 JavaScript. With 2, the compiler itself requires ES2015 support and outputs ES2015. Tools not running in a late-version Node environment might not run it correctly. I'd rather that tools need to be deliberately updated to support 2, and therefore the developer confirms that the runtime supports what CS2 expects (or a Babel step is added) rather than downstream tools just unceremoniously breaking. I realize that many such downstream tools are dormant nowadays, but that's all the more reason not to break them if we can help it.

@bd82
Copy link

@bd82 bd82 commented Feb 27, 2017

Thanks for the explanation @GeoffreyBooth.

I understand the desire to reduce unexpected breaking changes
but won't the fact that CoffeeScript 2 has a new major version solve this by using
standard semantic versioning?

Or is the intent here to avoid breaking changes even for those npm users which did not specify a version number in their dependencies?

  "devDependencies": {
	    "coffee-script": "*"
	  }
@jashkenas
Copy link

@jashkenas jashkenas commented Feb 27, 2017

@GeoffreyBooth — You can make the decision about how you'd like to handle it ... but I'd personally be fine with both coffee-script and coffeescript being simple mirrors of each other. That seems a little conceptually simpler.

@edemaine
Copy link

@edemaine edemaine commented Feb 27, 2017

FWIW, I do feel like it's somewhat expected that arbitrary upgrading of NPM packages will lead to breakage, especially to a new major version number -- that's why we have version-number-specific dependencies. And it seems there are some benefits to putting 2 on coffee-script as well... But I'm also happy that the project now has coffeescript -- that caused me some confusion in the beginning!

I should probably turn this into a separate issue, but can we have a tool (not sure if it belongs in coffeescript or as another package that depends on coffeescript and babel) that can run CS2 but generate ES3 code? Or perhaps just an example of how to do this in the README? I assume this is pretty trivial -- I just haven't had occasion to use Babel yet, and maybe many CS users are in the same boat.

@jashkenas
Copy link

@jashkenas jashkenas commented Feb 27, 2017

I should probably turn this into a separate issue, but can we have a tool (not sure if it belongs in coffeescript or as another package that depends on coffeescript and babel) that can run CS2 but generate ES3 code?

I think that's called "CoffeeScript 1".

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Feb 27, 2017

I think that’s called "CoffeeScript 1".

Not quite. CS1 doesn’t support async/await and a few other features added in CS2. There is a place for a build chain that involves the CS2 compiler → Babel → ES3. There are so many ways to implement this, though, and I feel like most people would want to do it within the context of a full-featured tool like Gulp or Webpack. I think we should document at least the simplest way, if there’s some way of doing this as a command-line one-liner (i.e. coffee -bpe foo.coffee > babel or something) and mention that it’s possible to do using full-featured build tools. If people write guides on how to do it via other ways, we can link to those guides.

I’d personally be fine with both coffee-script and coffeescript being simple mirrors of each other. That seems a little conceptually simpler.

And that’s probably what we should do. I’m not opposed—but I’m a lot more worried about breaking people’s builds, until we can be confident that releasing 2.0.0 on coffee-script is safe. I understand that Node projects should be fairly safe, since anyone who adds "coffee-script": "*" to their package.json should’ve known better, but what about all these non-Node downstream tools like the Ruby gem? Or even Node tools that themselves include CoffeeScript, like coffeeify. I think if we can survey the most popular ones and determine that either they used a fixed version of CoffeeScript or they use safe version restrictions (i.e. not "*") then sure, let’s make the packages mirrors of each other. But let’s do some research first.

@mrmowgli
Copy link

@mrmowgli mrmowgli commented Feb 27, 2017

@billymoon
Copy link

@billymoon billymoon commented Feb 27, 2017

Perhaps use coffeescript for CS2 right now, and defer the decision of what to do with coffee-script until bugs/tweaks/general response/learnings from CS2 have settled. That way it doesn't break the internet right now, and the decision can be made with more info at hand, also - as @mrmowgli suggests, it gives time for deprecation notice to be acted upon.

@balupton
Copy link

@balupton balupton commented Feb 28, 2017

Sweet. Can't wait to update the 60+ official DocPad repos over to it.

/cc @sdomagala

@laurentpayot
Copy link

@laurentpayot laurentpayot commented Mar 7, 2017

@MaxPleaner here are my webpack rules related to CoffeeScript. I'm using Vue.

      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: {
          postcss: cssUtils.postcss,
          loaders: merge({js: 'babel-loader', coffee: ['babel-loader', 'coffee-loader']}, cssUtils.styleLoaders({
            sourceMap: useCssSourceMap,
            extract: env.prod
          }))
        }
      },
      {
        test: /\.coffee$/,
        loaders: ['babel-loader', 'coffee-loader'],
        include: projectRoot,
        exclude: /node_modules/
      }

Remember not to use eslint with CoffeeScript. And create a symbolic link to coffee-script.

@YamiOdymel
Copy link

@YamiOdymel YamiOdymel commented Mar 7, 2017

@MaxPleaner I'm actually downloaded the index.js from the original coffee-loader, and changed the line

- var coffee = require("coffee-script");
+ var coffee = require("coffeescript");

and save it as coffee2-loader.js, then import it as the coffee-loader in WebPack like this:

resolveLoader: {
    alias: {
        'coffee-loader': path.join(__dirname, 'coffee2-loader'),
    }
},

so I can use it as normal coffee loader in Vue.js:

<script lang="coffee">
    ....
@light24bulbs
Copy link

@light24bulbs light24bulbs commented Mar 10, 2017

AWESOME you guys!

What about decorators? Some libs are starting to depend on them somewhat. I realize it's basically a total syntax collision as a decorator
@decorator

Looks exactly like a this.function to coffeescript. Maybe there could be some special syntax to denote that it is a decorator, instead of the @ symbol, since we have already used that for class variables.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 10, 2017

Let’s discuss decorators in #9

@mrmowgli
Copy link

@mrmowgli mrmowgli commented Mar 12, 2017

Hrmmm. Is there a way to tag @next on the npm coffee-script repo? I'm trying to dig into coffeelint, but I realize there are some deep dependencies that I want to try and break. Didn't Geoffrey mention we can have tagged versions that wont get pulled up with npm upgrade?

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 13, 2017

@mrmowgli yes, npm install coffeescript (no hyphen) pulls 1.12.4—you need to do npm install coffeescript@next to get 2.0.0-alpha1. But I haven’t put 2.0.0-alpha on coffee-script (hyphen) because I’m nervous of downstream tools that might be blindly installing the latest CoffeeScript without a version bound, and expecting it to run in a runtime < Node 7. See my comment above. If someone can do some research and verify that my concerns are unwarranted, especially for non-JavaScript wrappers around CoffeeScript like Ruby gems and the like, then I’m happy to put 2.x on coffee-script and make the two modules mirrors of each other. But I’d rather force the hassle of having people update their code to use coffeescript rather than coffee-script, if that avoids potentially breaking god knows how many projects that might use some gem or other ecosystem tool that just pulls the latest coffee-script.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 13, 2017

Happy to see some issues appearing in https://github.com/jashkenas/coffeescript! I mean, not that happy to see bugs, but at least it’s gratifying to see people using the new code 😄

I would consider only two features to-do before we can shift from alpha to beta:

  1. Destructuring #69. I’ve started a branch for this, which I’m happy to invite anyone to who wants to help. @YamiOdymel? Anyone? Help wanted!
  2. Getters and setters #17. @connec, do you think it might hopefully not be too hard to add support for the get and set keywords to the grammar? Do you have time for this?

Once these are in, the intended features of 2.0.0 will all be in, and we should be able to shift into beta because there shouldn’t be any further breaking changes (unless changes are forced on us in order to fix bugs). Then the beta period will be all about bugfixing and trying to get to 2.0.0. I’m hoping not to have too long of an alpha/beta period, to try to spur adoption of CS2.

@YamiOdymel
Copy link

@YamiOdymel YamiOdymel commented Mar 13, 2017

@GeoffreyBooth I'm sorry, I've spent two days on trying to find out how does the parser, lexer work (for example: [CS2] Compile all super calls to ES2015 super), but I still have no idea..

@jashkenas
Copy link

@jashkenas jashkenas commented Mar 13, 2017

  1. Getters and setters #17. @connec, do you think it might hopefully not be too hard to add support for the get and set keywords to the grammar? Do you have time for this?

Before we add getters and setters it would be nice to see examples of how they're necessary & desirable in modern JS.

They were always an intentional omission, despite popular support, from CoffeeScript. In my opinion, they're a "bad part" of JS.

Previously, in JavaScript, the reader could tell when they were calling a function and when they were reading a property. It's one thing in languages like Ruby, where direct property accesses don't exist, and everything is a function call — but JavaScript isn't Ruby. Getters and setters just add a level mystery and surprise to potentially every bit of code, and don't allow you to do anything you couldn't already.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 13, 2017

@jashkenas Can we take that discussion to #17? I wrote about it here.

@connec
Copy link

@connec connec commented Mar 13, 2017

  1. Getters and setters #17. @connec, do you think it might hopefully not be too hard to add support for the get and set keywords to the grammar? Do you have time for this?

I don't think that would be easy at all, unfortunately. We could do some shenanigans in nodes.coffee I expect but that would break referential transparency and/or allow unintentional syntax like get({ x: -> 42 }). I'll post a followup to #17.

@YamiOdymel my advice would be to not get too distracted by the parser and lexer, and focus on nodes.coffee which is where output generation happens. I barely had to touch the lexing or parsing to do all the class and super changes. nodes.coffee is much easier to work with and debug.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 13, 2017

@YamiOdymel All of the destructuring action happens in nodes.coffee‘s Assign.compileNode: https://github.com/GeoffreyBooth/coffeescript/blob/destructuring/src/nodes.coffee#L1688. @lydell added a bunch of comments to explain what’s going on there. Implementing ES2015 destructuring is really just rewriting that function to output ES2015 syntax instead of ES5.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Mar 29, 2017

I’ve started work on destructuring: jashkenas/coffeescript#4478 Help wanted! Please let me know if you’re interested and I’ll add you to the repo.

The only other issue to address before we go to 2.0.0-beta is the decision made in #17 (comment), where what looks like the get or set shorthand syntax (as opposed to a function call with parentheses, e.g. get(foo)) would throw an error.

We’re very close to the finish line, but the core contributors to the CS2 effort don’t have as much free time as we used to. We could really use additional help to get 2.0.0 out the door. Don’t just lurk in this repo, read this and get hacking! 😄 Ask not what CoffeeScript can do for you . . . 🙋

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Apr 4, 2017

Mini-update: The last two tasks for 2.0.0 are submitted as PRs for review and testing:

If you have time please take a look, and/or try them out in your codebases. Once these land, we will be at 2.0.0-beta1.

@GeoffreyBooth
Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth commented Apr 14, 2017

See #80.

@coffeescriptbot coffeescriptbot changed the title Progress as of February 2017: 2.0.0-alpha1! CS2 Discussion: Project: Progress as of February 2017: 2.0.0-alpha1! Feb 19, 2018
@coffeescriptbot
Copy link
Collaborator

@coffeescriptbot coffeescriptbot commented Feb 19, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.