Skip to content
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

The eslintrc should be overhauled for explicit Node v4 support #93

Open
appden opened this issue Jun 7, 2016 · 5 comments
Open

The eslintrc should be overhauled for explicit Node v4 support #93

appden opened this issue Jun 7, 2016 · 5 comments

Comments

@appden
Copy link
Contributor

appden commented Jun 7, 2016

It's currently set to use babel-eslint, which is allowing destructuring and other features that Node v4 (and even v5) do not support.

@Kureev
Copy link
Member

Kureev commented Jun 8, 2016

We need to use the same configure as react-native. We already merged rnpm into RN core, so I don't see a point of changing RNPM repo now. I think you'll be able to use some commands in the next release already 😉

@appden
Copy link
Contributor Author

appden commented Jun 8, 2016

Respectfully I disagree. If all the JS code for rnpm needs to be Node v4 compatible, then it should have an eslintrc that overrides the root react-native rules to restrict the acceptable syntax to what will work in Node v4. Nested eslintrc files will override ones in parent directories, and you could even use root: true to set it as the root rule set.

P.S. Very excited about rnpm being merged into React Native. Congrats!

@Kureev
Copy link
Member

Kureev commented Jun 9, 2016

Well, I think you're mostly correct. The only thing is that react-native requires node v4+ as well, so I though mb it can fit for rnpm too, because we don't want to introduce yet another code style in subfolder

@appden
Copy link
Contributor Author

appden commented Jun 9, 2016

I agree about the code style, that's why I think the eslintrc should just disable ES6 features that are known not to be supported by Node v4, but not mess with style rules inherited from the parent.

@Kureev
Copy link
Member

Kureev commented Jun 10, 2016

Ok, sounds reasonable 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants