Any clarification for npm info coffeescript?

     '1.12.4',
     '2.0.0-alpha1',
     '99.999.9999',
     '99.999.99999' ],

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

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

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.

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.

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?

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

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

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

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

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 😄

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

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

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

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

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!

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:

• greenkeeper.io which automatically create pull requests to update dependencies.
• David-dm - displays a table of dependencies.
• npm-check-updates - CLI to update package.json deps.

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.

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.

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": "*"
	  }

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

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.

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

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.

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.

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

/cc @sdomagala

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

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

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.

Let’s discuss decorators in #9

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?

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

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 CS2 Discussion: Output: 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 CS2 Discussion: Features: 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.

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

@YamiOdymel did you see https://github.com/jashkenas/coffeescript/wiki/%5BHowTo%5D-How-parsing-works?

2. Getters and setters CS2 Discussion: Features: 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.

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

2. Getters and setters CS2 Discussion: Features: 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.

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

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

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

• Destructuring
• get/set warning (and placeholder if we decide to support that syntax someday)

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.

See #80.

Migrated to jashkenas/coffeescript#4964