Skip to content
This repository has been archived by the owner on Aug 18, 2021. It is now read-only.

Enable subset of syntax. #434

Closed
gdborton opened this issue Jan 20, 2017 · 7 comments
Closed

Enable subset of syntax. #434

gdborton opened this issue Jan 20, 2017 · 7 comments

Comments

@gdborton
Copy link

Is there a way to enable a subset of the babel supported syntax? We're hoping to use this to use this parser to enable import(), but aren't ready to enable other babel transforms with our code base, and would like for them to continue to be syntax errors as they won't be transformed.

@gdborton gdborton changed the title Enable only certain syntax. Enable subset of syntax. Jan 20, 2017
@ljharb
Copy link
Member

ljharb commented Jan 20, 2017

It would be really nice if babel-eslint could be configured using parserOptions to simply read our babelrc, and error out on anything that's not transformed.

@hzoo
Copy link
Member

hzoo commented Jan 20, 2017

@ljharb Shouldn't babel be already erroring if you don't use a certain syntax? Unless you mean something thats already in the "spec" like async

@ljharb
Copy link
Member

ljharb commented Jan 20, 2017

As discussed in Slack, a goal is to have the linter error out - ideally in the dev's editor - long before the much slower build process.

@magnushiie
Copy link

Also, there could be conflicts between plugins (or bugs in babylon, e.g. babel/babylon#392) which for some projects could be irrelevant if they could be turned on selectively (e.g. jsx could be turned off for a backend project).

@zertosh
Copy link
Member

zertosh commented Mar 28, 2017

@ljharb have you considered http://eslint.org/docs/rules/no-restricted-syntax ?

@ljharb
Copy link
Member

ljharb commented Mar 28, 2017

@zertosh i'm well aware of that rule, given that i'm the one that suggested its initial creation. The problem isn't that I can't block syntax; it's that it's incredibly laborious and error-prone to map a given babel config to the list of syntax productions I want to type - and, that rule can't block new syntax types as new proposals are introduced - which means the rule just isn't sufficient.

Having untransformed code pass the linter is a babel and babel-eslint problem, and I think it's appropriate for babel-eslint to be the place to fix it.

@hzoo
Copy link
Member

hzoo commented Jan 11, 2019

Should be like #573 and handled by #711 now!

@hzoo hzoo closed this as completed Jan 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants