@babel/eslint-* v8

[kaicataldo]

Making an issue here to track the work that needs to be done for the new @babel/eslint-* packages for the v8 release.

@babel/eslint-parser (taken from https://github.com/babel/babel-eslint/milestone/1):

• add support for preset & plugins in babelOptions We can add this in a later minor version if need be.
• 11.0.0-beta.0 - Private class methods no-undef error This is not an issue specific to babel-eslint since the error is being thrown by @babel-core and the example code doesn't compile either.
• 11.0.0-beta.0 - Private Instance Methods - Parsing error: params is not iterable - Dupe of Could not traverse ClassPrivateMethod when estree plugin enabled #9506 @babel-core: parse should parse only #10914
• 11.0.0-beta.0 - Typescript interface/type no-undef error I don't think we should consider this a blocker for v8, since TS support is currently fairly limited. I think it makes sense to focus on making TS support more robust in the future, though I'm still of the mind that folks should just use typescript-eslint.
• Doesn't work with custom parser through parserOverride I don't think we should consider this a blocker for v8.

@babel/eslint-plugin

• Template string failing with Cannot read property 'range' of null #10904
• Ensure ClassPrivateProperty works correctly with no-unused-vars and no-undef. @babel/eslint-parser: update scope analysis for ClassPrivateProperty #10913
• Can we create a shared config that enables the parser and corresponding rules automatically? I no longer think this is a good idea because ESLint doesn't provide any runtime hooks to see what the user has configured. Turning off incompatible rules works, but we can't enable the corresponding rule in our plugin.
• Audit current rules to see if they need to exist. @babel/eslint-plugin: remove deprecated rules #10975 @babel/eslint-plugin: Update rules/tests to use @babel/eslint-parser #10977
• Remove deprecated rules? @babel/eslint-plugin: remove deprecated rules #10975
• Figure out how we can be more proactive rather than reactive. Run core rules over fixtures that contain new experimental syntax? Fuzzer?
• semi: never not working with do expressions babel-eslint#814

@babel/parser

• Update ESTree plugin to output spec-compliant AST
• RegExpLiteral is not converted to Literal in an edge case

Please feel free to edit this comment or discuss below.

[kaicataldo]

Thoughts on this current list? I'd love to evaluate the additional options proposed in the issues above for @babel/eslint-parser in particular.

[kaicataldo]

I'm not sure this should be a high priority for the v8 release: babel/babel-eslint#786. While it would be nice to support this, this feels like an edge case that, if we do support, might open up another can of worms. Thoughts?

[kaicataldo]

Also wanted to note that we should probably wait for estree/estree#204 to be finalized before updating the ESLint packages so that we don't duplicate any work.

[nicolo-ribaudo]

Remove unnecessary rules from the plugin: babel/eslint-plugin-babel#188

[jharris4]

@kaicataldo Thanks for bringing our attention to this issue. (and for all your work on this package!) It's nice to see that this package is still being actively maintained, albeit in a new repository.

Under @babel/eslint-parser in the first comment above, you mention that babel/babel-eslint#784 can be included in a future release. While I understand the logic, that would be a shame since the code itself is a 2 line change! Also I made a PR with tests for that change 8 months ago for a dependent project that really needs this change, and is using a forked published package to workaround it for babel 7.

I'd be willing to make a PR with the same 2 line change to this repo, but (as always?) the tricky bit would be adding the tests. This will be a bit harder in this repo since the structure of the tests has changed considerably, and I'm not really sure where such tests would belong since there don't seem to be any other tests related to the configuration logic.

If we'd be open to a simpler route, we could even forgo the tests (shocking/terrible I know!) but then again there are no other tests for cases where the contents of the config file change, and really all that adding support for presets and plugins does as part of the babelOptions option is give a bit more flexibility to how the configuration is specified, and in fact brings the arguments more in line with what the loadPartialConfig function from @babel/core already accepts. Basically they're just pass through arguments!

I'm fairly busy with work so I don't have much more time to devote to this, but if we can decide on a happy compromise , I'd be happy to open a new PR. I can add tests as well if necessary if you can offer guidance on how to do so without too much work.

[ghost]

The package @babel/eslint-parser isn't available yet (contrary to the README of it in the babel monorepo). Should users like me just use this package for now?

[kaicataldo]

@GitGangGuy We haven't published the new @babel/eslint-* packages yet. The current plan is to release them with the Babel v8 release. In the meantime, we recommend using babel-eslint. Thank you for your patience!

[nicolo-ribaudo]

@kaicataldo Maybe we can add a note in the READMEs?

[sKopheK]

Hi, any estimated date when is the new version available with fixed @babel-core supporting private class methods? (sorry if it's not an appropriate thread, couldn't find any better)

[kaicataldo]

@sKopheK The current plan is to release these packages with Babel v8.

[bunday]

Keeping a tab on this till it is released.

[mattlubner]

11.0.0-beta.0 - Typescript interface/type no-undef error I don't think we should consider this a blocker for v8, since TS support is currently fairly limited. I think it makes sense to focus on making TS support more robust in the future, though I'm still of the mind that folks should just use typescript-eslint.

I'm a little perplexed by the statement "folks should just use typescript-eslint". For projects using babel to enable non-standard language features inside TypeScript files, I don't think it's possible to use typescript-eslint, right?

For context, I came here via babel/babel-eslint#832 (which looks to be fixed by #9529), so I'm very eager to see that fix in a non-beta release! 🙂

[kaicataldo]

For projects using babel to enable non-standard language features inside TypeScript files, I don't think it's possible to use typescript-eslint, right?

This is correct. We've historically struggled to maintain compatibility with ESLint for plain old JavaScript, so it's hard to prioritize supporting TypeScript in @babel/eslint-parser. The challenges we would face:

• The bulk of the work would be duplicating the work in @typescript-eslint/parser.
• There's added complexity in that we would have to not only ensure compatibility with ESLint but also to match the AST structure of @typescript-eslint/parser so that rules written for @typescript-eslint/parser would also work.
• The parser would be incomplete because @typescript-eslint/parser allows rules to access type information.

I'd be curious how many people actually run a double compilation step like this, since it seems like you would lose some benefit of type-checking (unless the Babel transform adds the types to the compiled output?).

[mattlubner]

[…] it seems like you would lose some benefit of type-checking (unless the Babel transform adds the types to the compiled output?).

It took me some time to understand what you meant by this. The main benefit of TypeScript is static typing (ie. type-checks are performed by static analysis tools, like eslint), so losing type information shouldn't matter at runtime. However, it matters hugely during static analysis. TSC can't parse Babel-specific syntax, Babel can't natively parse TypeScript syntax, and @babel/preset-typescript strips out type information (as of v7.10.0), so there's apparently no way to statically analyze the types in TypeScript files if they also contain Babel-enabled syntax. 😕

I'd be curious how many people actually run a double compilation step like this, […]

Because of this drawback, probably not many. This approach isn't without benefits, however: It retains all of the platform-agnostic benefits of using Babel, and it also eases the process of migrating to TypeScript in projects already using Babel.

However, the number of folks currently using this approach doesn't say anything about how many would like to. I'd imagine the entire JavaScript community would want Babel and TypeScript to be more compatible! As far as I can tell, this drawback is the only remaining barrier.

By the way, I'm relatively new to TypeScript, so please correct me if any of the above is wrong, or if I've overlooked something!

[kaicataldo]

The main benefit of TypeScript is static typing (ie. type-checks are performed by static analysis tools, like eslint), so losing type information shouldn't matter at runtime.

I was referring to using static analysis tools rather than at runtime. What I'm curious about is if Babel transforms also include the type transforms so that tsc still has explicit type information (obviously it can do its best, regardless).

[mattlubner]

What I'm curious about is if Babel transforms also include the type transforms so that tsc still has explicit type information (obviously it can do its best, regardless).

I think the answer to your question is that Babel transforms don't include type transforms, at least as of Babel v7.10.0.

The Babel docs for @babel/plugin-transform-typescript say:

This plugin adds support for the syntax used by the TypeScript programming language. However, this plugin does not add the ability to type-check the JavaScript passed to it. For that, you will need to install and set up TypeScript.

[kaicataldo]

This has now been released!

[kaicataldo]

@mattlubner Would you be willing to make a new issue so we can discuss how we can better support TypeScript in @babel/eslint-parser? This issue was intended to track the work to get these new packages out the door.

[jharris4]

This has now been released!

Very cool! I tried in vain to find the release. Can you share a link please?

[DRoet]

This has now been released!

Very cool! I tried in vain to find the release. Can you share a link please?

Should be part of the v7.11.0 release.

[jharris4]

Should be part of the v7.11.0 release.

Ahh! Given the title of this issue I was looking for a v8 release!

[kaicataldo]

Ah, yeah - sorry for the confusion! We originally intended to release this with v8, but we didn't want to hold it up until v8 is ready.