-
-
Notifications
You must be signed in to change notification settings - Fork 209
Enable subset of syntax. #434
Comments
It would be really nice if |
@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 |
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. |
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). |
@ljharb have you considered http://eslint.org/docs/rules/no-restricted-syntax ? |
@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. |
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.The text was updated successfully, but these errors were encountered: