reactjs/sublime-react deprecation about babel-sublime HOT 24 CLOSED

Are you going to add syntax highlight for *.cjsx files (Coffee Script React)? That would be cool. Thanks.

from babel-sublime.

With this deprecation, support for CJSX dissappeared. All of my files now look like shit. Is there any chance you will support CJSX aswell?

from babel-sublime.

CJSX :(

from babel-sublime.

I'm afraid that I have no plans of adding CJSX support since babel doesn't support coffeescript syntax. Maybe @jsdf can take old CJSX syntax definitions and maintain them?

from babel-sublime.

Kinda surprised by this deprecation.

@JakovlevDS @miklschmidt @vegetableman

You guys could just copy and paste the following as a new sublime package (or into your sublime user folder): https://github.com/reactjs/sublime-react/tree/ec17f5dfd00eaa326dc299a4febd46cac21e7904/syntax/jsx-coffee

@zertosh What do you mean by "bring back snippets"?

from babel-sublime.

@dashed I'm going to add back the React snippets and some new ES6 ones as a separate package so they can be opt-in and independent of the syntax definition. https://github.com/babel/babel-sublime-snippets

from babel-sublime.

Just adding in my support for CoffeeScript support! Thanks for your time and effort :)

from babel-sublime.

cjsx :(

from babel-sublime.

FYI sublime-react in its current state already/still provides snippets. I'm not sure it's worth duplicating that effort, unless your focus is making them customizable based on your transform configuration. Not everyone using snippets is using Babel.

from babel-sublime.

Re: CJSX, I'd encourage the coffeescript community to maintain a separate project altogether. Supporting both languages in sublime-react was –in hindsight– not a great move, since all of React, JSX and ES6 tend to introduce changes at different points in time. I realize that this is an inconvenient transition for coffeescript users, but it should make future upgrades easier for both sides.

from babel-sublime.

@jgebhardt We had snippets but then I removed them (see #31). I've been meaning to make a package just for them, now seems like a good time.

As for CJSX, I'd be more than happy to add a link to whatever project takes over it.

from babel-sublime.

@zertosh I understand they were removed, but sublime-react already provides snippets (actually, since removing the syntax in favor of Babel, that's all it provides). I don't plan on removing the remaining package, as many people are using it specifically for snippets.

What improvements do you envision babel-sublime-snippets to provide over sublime-react?

from babel-sublime.

@jgebhardt More ES6 specific stuff like import, something for arrow functions, etc. And as far as React stuff, things like import React, {PropTypes} from 'react;, a skeleton for React ES6 classes, etc.

I based the original snippets on what was on sublime-react, but I switched them to using ES6 syntax, like short method definitions. They're all listed here https://github.com/babel/babel-sublime/blob/master/SNIPPETS.md.

from babel-sublime.

The deprecation was extremely annoying. Why can't we have both babel and reactjs (seriously, there is no legitimate reason to completely break it - sure stop supporting it/working on it, but don't just make it stop working)? It took me a while to even realize there was a deprecation, I had to look at the repo and see the latest commit.
/rant

from babel-sublime.

@n1ghtmare i agree, it's not cool deprecating (actually not deprecating, directly removing without warning) something without a proper substitution. Is there anyone with experience in syntax definitions who could maintain a new repo? If not i'll take a look at throwing together a repo and sublime package, but i have no idea what i'm doing.

from babel-sublime.

As it appears that CJSX will never be supported in this package, I recommend migrating our efforts to aponxi/sublime-better-coffeescript.

from babel-sublime.

It is definitely not cool to wake up one morning and seeing your cjsx files in sublime look like plain text files without having any proper feature substitution. Before deprecating something unexpectedly I would expect authors to think about all user current using the plugin and giving them time to adapt accordingly. Thanks for taking them into account next time.

from babel-sublime.

@alanrubin I absolutely agree, that was definitely not cool. I ended up setting auto_upgrade to false and restoring the Packages folder.

from babel-sublime.

@alanrubin @n1ghtmare The repo is still there. All you have to do is clone it and point it to the commit before the deprecation.

git clone [email protected]:reactjs/sublime-react.git
cd sublime-react
git checkout ec17f5d

from babel-sublime.

@zertosh Yep, thanks, that's what I did, I've created a fork (then reverted the changes) and added it as a source to Package Control. Then set auto_upgrade back to true.

from babel-sublime.

I've got a package hosted here, with the non-syntax highlighting stuff removed:
https://github.com/Guidebook/sublime-cjsx

You can add this as a repo manually.

Also improved the highlighting a wee bit -- it wasn't highlighting HTML attributes in the sublime-react version

from babel-sublime.

For those unaware, adding @kwood's repo manually involves:

1. Cmd/Ctrl+P > Package Control: Add Repository > https://github.com/Guidebook/sublime-cjsx
2. Cmd/Ctrl+P > Package Control: Install Package > sublime-cjsx
3. Open a *.cjsx file
4. View > Syntax > Open all with current extension as... > CJSX

from babel-sublime.

Thanks for sharing the detailed steps. @chrisvfritz . you rock 👍

from babel-sublime.

Thank you @kwood @chrisvfritz, this is VERY helpful!

from babel-sublime.