-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CS2 Discussion: Project: CoffeeScript 2.0.0 #4932
Comments
From @GeoffreyBooth on 2016-09-16 05:02 Also in 2.0.0 would we get rid of the top-level function safety wrapper? It’s already disabled for any file with an EDIT: branched off as coffeescript6/discuss#38 |
From @mrmowgli on 2016-09-16 07:23 The top level safety wrapper is actually useful in certain situations, although I admit I personally haven't used it in quite a while. Perhaps as another issue and a poll? Also Github just added the Projects tab, any interest in using that for this project? |
From @lydell on 2016-09-19 06:00 I like the proposed release scheme of 2.0.0-beta1, 2.0.0-beta2, etc. I also like the idea of adding non-breaking changes to 1.x. 👍 from me. |
From @jashkenas on 2016-09-19 17:54 Sounds fine to me, but speaking generally "beta" implies feature-completion that still needs bugfixing. Instead, call it "alpha".
|
From @GeoffreyBooth on 2016-09-19 18:12 Sounds good to me. Okay, I’ll treat this as our plan for moving forward. |
From @GeoffreyBooth on 2016-09-19 18:29 Should we start this work in a As part of 2.0.0 I think we should also prioritize clearing out the backlog of open pull requests on coffeescript.org; especially the ones that only affect downstream tools, like fixing location data. I suspect that those have been ignored because they have no effect on the CoffeeScript compiler and could introduce bugs or breaking changes . . . but 2.0.0 might be the place to deal with that. These fixes will probably end up helping us farther down the road if we implement a new compiler. |
From @jashkenas on 2016-09-19 18:48 To avoid breaking people unnecessarily, let's leave |
From @kirly-af on 2016-09-27 19:11 @GeoffreyBooth Just had a look on the Features page. IMHO, not being able to output I know this is defo not the right place to talk about it, but I think this SHOULD be part of CS2 (and actually why not CS1) as soon as possible. |
From @lydell on 2016-09-27 19:15 |
From @kirly-af on 2016-09-27 19:36 @lydell: Sad to see we're going for a third |
From @GeoffreyBooth on 2016-09-27 19:41 I thought of that as more of a 1.x feature and that’s what it wasn’t on the Features page, but it’s definitely a priority. I haven’t looked too deeply into it, but I gathered from the discussion that there’s no way to avoid a third |
From @kirly-af on 2016-09-27 20:45 Agreed. |
From @atg on 2016-09-30 22:34 Yes for-from is intended to be a 1.x feature, that simply completes the triangle of In my mind, there's two clear categories of changes:
If the second group of changes are implemented under a flag, then there's potentially no backwards compatibility issues at all, and so no need for a 2.x (in semver terms). I would prefer a situation where we can do |
From @GeoffreyBooth on 2016-09-30 23:28 @atg As discussed here and in coffeescript6/discuss#34, a flag adds a lot of complexity that we don’t want to deal with. We’re going with the 2.x branch and version number. |
From @atg on 2016-10-01 01:03 @GeoffreyBooth Presumably most changes would be confined to |
From @GeoffreyBooth on 2016-10-01 01:09 There are also changes to the grammar. I'm sorry, but it's not worth the complexity. |
From @atg on 2016-10-01 01:18 Should I reply in the #34 or here? I want to be able to use ES6 features with node.js. But also I have to write code that runs in web browsers (that do not have ES6 support). I have no intention of using a transpiler because that would break |
From @GeoffreyBooth on 2016-10-01 02:42 It’s not that hard. When 2.x is out, you could install it globally: npm install -g coffee-script And within your project folder, install an older CoffeeScript: npm install coffee-script@1.11.0 And then run 2 via Or clone the CoffeeScript repo and create a symlink to it: cd ~/Sites
git clone https://github.com/jashkenas/coffeescript.git
git checkout tags/1.11.0
ln -s /usr/local/bin/coffee1 ~/Sites/coffeescript/bin/coffee Then use Or use Gulp or Webpack or Grunt or any of their competitors. Or fork CoffeeScript, rename the binary in your version, and install that globally alongside the regular CoffeeScript also installed globally. Or go nuts and install Docker and use separate Docker images for compiling with various versions of CoffeeScript. There are many ways to solve this problem without needing to complicate the CoffeeScript codebase. |
From @atg on 2016-10-01 03:36 I understand that. It is not too hard for me and I will probably just install both versions. But it is more awkward than things currently stand. Surely I am not the only user who will be affected by this. The philosophy of 2.x seems to be "damn ES5 compatibility in the core language, let's convert the entire codegen to ES6!". I am questioning whether this is a good idea. If we take each feature in turn, most features are syntactically opt-in and so can be implemented without 2.x or a flag. Of the non-opt-in features, ES6 classes are the most useful and implementing them under a flag would not create great complexity in the CoffeeScript codebase. So what remains? let/const? rest parameters? Does the gain of these invisible codegen changes outweigh the pain to the workflow of using CoffeeScript? I really don't get it but maybe I'm just old. |
From @GeoffreyBooth on 2016-10-01 03:58 Classes are in a class (sorry) by themselves, and absolutely need to be implemented ASAP. It’s a breaking change, unfortunately, and that’s really what’s triggering this whole effort. The only other “major” features getting worked on at the moment are And there are several good reasons to modernize the output:
|
From @jonnor on 2017-02-08 15:48 Should the binary be available with a different name, since it is incompatible with the old one? For instance |
From @GeoffreyBooth on 2017-02-09 01:26 I’m not sure what you mean by “incompatible with the old one.” There are a small handful of breaking changes in CoffeeScript 2, but most code should run as is without requiring significant changes. Node 7+ will run CoffeeScript 2’s output without further transpilation, aside from modules (the same as today with 1.x). I don’t anticipate people keeping both versions installed globally on their machines. |
From @GeoffreyBooth on 2017-05-15 07:07 Update: in 1.12.6 and soon to come in 2.0.0-beta2, you can have separate versions of CoffeeScript installed globally and locally in a project, and the cd path/to/your/project
npm install --global coffeescript@next # Install 2.x globally
npm install --save coffeescript # Install 1.x locally in this project
coffee -v # 1.x
cd /
coffee -v # 2.x |
From @GeoffreyBooth on 2017-09-03 08:14 Closing per coffeescript6/discuss#88. |
From @GeoffreyBooth on 2016-09-16 04:40
Branching off from coffeescript6/discuss#34, this is a place to discuss a potential
2.0.0
release of CoffeeScript. The proposed 2.0.0 release will include breaking changes, and have two major features:class
keyword. See CS2 Discussion: Output: Classes coffeescript6/discuss#22.I think we should release
2.0.0-alpha1
as soon as classes are ready. We would also add a note on coffeescript.org that 2.0.0 is in alpha and subject to further breaking changes, which would be released as2.0.0-alpha2
and so on until we’re pretty sure we have no further breaking changes for the 2.x major version.The other features on our list that aren’t breaking changes (tagged template literals, await) can be released either on the 1.x branch or the 2.0.0-alpha branch. They should be implemented only as ESNext output, regardless of branch.
We should try to define exactly which features will have their output changed to ESNext. Here and here are comparisons of CoffeeScript features to new ES2015 features. Here is a pretty concise list of features introduced by ES2015. I’ve started a GitHub project where we can put cards into columns to define what features we want to update.
The other big issue is what to do about
const
/let
and block scoping. Let’s please hash out an approach to that one over in coffeescript6/discuss#35, to not overwhelm this thread. Also if we can, let’s please keep discussion of whether we want to refactor or replace the compiler over in coffeescript6/discuss#25.The text was updated successfully, but these errors were encountered: