@JoshuaKGoldberg I don't feel comfortable posting publicly who the integrators are, as I didn't specify to them that I'd be sharing with everyone. We can follow up offline.

With regards to the second question, these would be environments where integrators are using the ESLint API directly in their product rather than installing and using the CLI.

using the ESLint API directly in their product rather than installing and using the CLI.

But how did they get the ESLint API..?

They had to fetch eslint at some point in the pipeline via npm et al or else they wouldn't have access to the ESLint APIs.

How do they deal with 3rd party plugins and configs if they don't do an install?
It's a very, very rare case that any modern eslint setup relies on eslint core and nothing else - so surely they'd need to have a mechanism to fetch/install 3rd party plugins.

I'm not sure the technical details are important for this conversation. I can only convey what I've been told.

Further, you're thinking more like a user than an integrator. Integrators don't necessary want to load a eslint.config.js file to determine what to do. They frequently write their own rules that they want people to use in addition to core rules. ESLint isn't just a CLI tool, it's also a linting framework that people can use in a variety of different ways. Whether we think such a case is common or not, it happens, and it happens for people who are charging money for access to the project that does it.

To me at least it just seems like a weird usecase for ESLint as a project to optimise for. Should we be making it easier for 3rd parties to bundle up and sell eslint?

At least for me as a FOSS maintainer - I abhor the idea that someone would be doing such a thing - profiting directly off of all the hard work that we give for free.

It also seems like a fraction of a percentage of the overall userbase of eslint. Like eslint has 32m weekly downloads and obviously that doesn't translate to 32m users - but no matter how you slice it up - it's a very large userbase. This commercial usecase would barely service a fraction of users in comparison.

The commercial integrators use case is just a part of the story, not the whole story. This proposal isn't about optimizing for them, it's about optimizing for the entire ecosystem where there seems to be shared pain. The pain comes about in different ways for different constituents and I thought discussing this lesser-considered use case would be helpful context, but I don't see it as the driving force.

This is correct - typescript-eslint only operates in an uncacheable way when type-aware linting is enabled. Without type-aware linting it operates solely on a single file without additional files (it essentially just creates a ts.SourceFile and grabs the AST from that) so it is fully cache-able.

Though worth noting that a lot of TS users also reach for type-aware rules or cross-module rules from other projects (like eslint-plugin-import) so that's why it's so common to not use caching and it's our default advice to people.

It's worth noting that tsc itself is a slower parser than other options.
I think in part this is because it's not designed to be strict - it's made for the IDE usecase where it needs to be forgiving. This means that it has to make some decisions that slow it down a bit.

So a "new" parser could speed up the non-type-aware case. But obviously that comes at the cost of not being able to ever use type-aware linting.

Thanks for the clarification on caching, I did forget that it was the type-awareness that made caching not work. I'll update my original post.

Yes, eslint-plugin-import is another thing we're needing to think through to enable caching for more folks. As people complain about performance, I think we need to be more explicit about when they are opting into things that will explicitly make things slower (either by actually being slower or by removing caching from the equation).

That doesn't affect the plans in any way. We'll continue to support JavaScript-standard features as they come out. There's still a lot of TypeScript-specific syntax that needs to be considered.

I did mention the virtual filesystem when talking with integrators, and the response was something along the lines of, "yea, we don't like that." My sense is that embedding the typescript package and keeping it in sync with typescript-eslint plus wiring up a virtual file system was more coordination than they felt like doing for each release of typescript and typescript-eslint.

What existing solutions are you talking about?

SWC, oxc, babel, typescript-eslint are all examples of parsers usable from JS to parse TS.

IIRC also hermes-parser supports TS and even has an ESLint parser. Note: hermes is what the flow community uses to lint flow code.

There are many parsers that exist and they would all work given the right efforts to get the AST representation right.

And what is the comprise you're referring to?

By that I meant that you could pick any existing solution and not compromise anything - the choice would be transparent to users.

As in - they all parse the same syntax and would all be roughly equally performant. ESLint doesn't have any other unique constraints hence they'd all work without having to make compromises.

FWIW in the testing I've done benchmarking the Babel parser vs TypeScript's parser: Babel was slightly faster for smaller files but as the file size grew TypeScript ended up being faster. Additionally traversing TypeScript's AST was consistently faster. The pattern which caused the largest perf problem with accessing the TS AST was doing so in a type safe way, specifically using the ts.isABC predicates. Because these access node.kind (megamorphic) they are comparatively slow. Reducing visits to only access node.kind once was a significant performance boost.

I'm also pretty -1 on the idea of creating a new parser. It creates a lot more work for what I see as minimal benefit. A couple of additional reasons to what's been stated in this thread, focused on type-aware linting...

Ergonomics: TypeScript's APIs require taking in a TypeScript AST node. Furthermore, the TS Program APIs require using nodes from that same TS Program. You can't pass in a TS node from some other manually created source file (microsoft/TypeScript#28413).

One of the big benefits of the typescript-eslint approach (parse with TypeScript -> create an TSESTree equivalent) is that you can directly pass in the equivalent TS node for any TSESTree node. Moving to some other parser means type-aware rules would have to add a separate conversion layer to create a TS Program anyway. So, no matter what, much of the work being done by the current parser must be done for type-aware linting.

Performance: When linting with type information, text->node parsing performance is generally not a bottleneck. Time spent in TypeScript type retrieval APIs is practically always a strong majority of time spent for most projects. We've done a ton of work in typescript-eslint to optimize performance - and we've almost never identified or had reported to us a significant slowdown from text->node parsing.

The closest investigation was @bradzacher having an idea with typescript-eslint/typescript-eslint#6149 -> typescript-eslint/typescript-eslint#6371. The results there were that even with a 10% reduction in text parsing time, the net reduction in overall time was only ~0.2%. That was because lint rules themselves take up most lint timing.

Right, this is why I listed a disadvantage as the loss of type-aware linting. However, that could only be temporary. I feel like there's a lot of low-hanging fruit for ESLint to be at least nominally type-aware.

There've been efforts to get surface-level type awareness here and there. We could consider the astUtils.getStaticPropertyName & related functions in ESLint to be a version of that. I'd wager you could get somewhat far with basic AST checks in a file for many functions, and even further with a basic TypeScript parser that builds up a scope manager for each file & effectively looks up where identifiers are declared.

The tricky point is that most larger TypeScript projects end up using complex types somewhere in the stack. Any modern ORM (e.g. Prisma, Supabase) or schema validation library (e.g. Arktype, Zod) employs conditional types and other shenanigans. Not being able to understand those types blocks rules from understanding any code referencing those types. Inconsistent levels of type-awareness could be very confusing for users.

@nzakas just drawing this to your attention. I think whether ESLint core supports TypeScript types is a big question separate from supporting TypeScript syntax. As I see it, there are three main paths that could be taken:

• Not having a built-in types provider: so core rules have no concepts of types, and extension rules will need to add them in
• Having a built-in types provider, but having it be AST-only or similar (i.e. allowing the drawbacks noted in Rethinking TypeScript support in ESLint #18830 (reply in thread)): so a project like typescript-eslint would need to plugin TypeScript's types into there
• Having TypeScript be the built-in types provider

I agree. I think the baseline I have in mind is supporting TypeScript syntax.

keeping everything in sync every 3 months is much easier to do if they're all in the same repo.

Agreed. This is exactly what I proposed above with merging changes into the parser/scope manager/visitor keys that we have in the eslint/js repo. In fact, that's why we've merged these into the same repo. 😄

Just as a note: ESLint supports ECMAScript features as soon as they reach stage 4, which tends to happen during the course of the year rather than all at once when the final spec is approved.

Wouldn't this allow TypeScript syntax in non-TypeScript files?

In addition to the IDE complaints and runtime checks, it would be pretty straightforward to add a parser check in non-TS files for TS syntax. If it sees any of the TS-specific nodes, it can throw an error.

In general, I don't think it would be a good move for an independent project like ESLint to so tightly couple itself to a corporate-driven project like TypeScript.

Could you expand on this, please? Given all the reasons in the other threads around why it'd be difficult to use a non-TypeScript parser for TypeScript code, it'd be helpful to know what downsides you're trying to avoid.

Given all the reasons in the other threads around why it'd be difficult to use a non-TypeScript parser for TypeScript code, it'd be helpful to know what downsides you're trying to avoid.

The tl;dr is that we need to have control over our core dependencies.

We learned this the hard way early on when we were built on esprima, escope, and estraverse. Slowly, we realized that we were stuck based on the whims of the maintainers of those packages and so we forked everything. (As an interesting side note: at first we forked esprima to espree, but it was too hard to work with to update. So we switched over to using Acorn as the base specifically because it was completely pluggable and so had a fairly sane interface for making changes should Acorn itself every fall out of maintenance.)

Being tied so tightly to a Microsoft project would give us massive supply chain risk exposure over which we have no control.

Plus, I personally don't think it's actually hard to use a non-TypeScript parser for TypeScript code. As already mentioned, there are a ton of alternative TypeScript parsers powering other tools (written in Rust, alas), so this seems far from an untenable approach.

Plus, I personally don't think it's actually hard to use a non-TypeScript parser for TypeScript code

It's not hard, no, in a general sense. It's very doable to build a parser - heck there's even existing plugins for acorn to parse TS.

There are complicating factors though.

Any new parser would need to match the existing AST spec or else the current ecosystem would break.
This is the same reason we strongly recommend against using @babel/eslint-parser for TS -- sure it'll work, but it has a different TS AST than @typescript-eslint/parser and so the ecosystem can break (note: We track differences between the ASTs as part of the above spec).

We would need to have some form of parser validation testing to ensure AST shapes are the same between implementation, and would also need to take care to ensure we're pre-planning AST before each new syntax added so that both projects can keep in sync (similar to https://github.com/estree/estree).

I personally don't think that this doubling of implementation / maintenance burden really serves anyone in the ecosystem or either maintenance teams. As volunteers we're all bandwidth constrained and there's barely enough bandwidth to go around as it is -- IMO it makes more sense to double down on one approach and focus efforts there so that we can reduce workloads and focus on bigger and better problems.

Being tied so tightly to a Microsoft project would give us massive supply chain risk exposure over which we have no control

I'm not sure I understand. Why is there risk here? What's the problem with Microsoft owning TypeScript? They've run the project openly and successfully for 12 years (their first npm release was before even eslint's first npm release) and it's now a pillar of the community. The TS team themselves are very approachable and friendly and are open to working with us to improve the state of linting.

I'd love it if you could elaborate on the perceived risk.

I'm not sure how to elaborate over and above what I already stated above. I'm not willing to have a hard dependency on any project over which we don't have any control, or at least, one where we don't have the option of swapping out to something else. That's a giant risk for ESLint which would leave us scrambling should something happen to the TypeScript parser. (And this isn't a Microsoft or TypeScript thing, I'd have the same reaction if anyone asked us to rely so heavily on a company-sponsored project.)

To reiterate: there's a reason we forked Esprima to create Espree, and why we eventually forked the projects we relied on.

I personally don't think that this doubling of implementation / maintenance burden really serves anyone in the ecosystem or either maintenance teams.

I don't see it as that high of a burden. You folks decide what you want the AST to be, let others follow. I've already been prototyping this out by running the typescript-eslint parser to generate ASTs and then running my prototype against that to validate.

Honestly, we don't need ESLint to handle type checking since TSC can be run in a separate CI job. ESLint should focus purely on linting, regardless of the language.

I think you've misunderstood what nick is talking about with regards to performance problems here.
ESLint and typescript-eslint both do not do type-checking.

typescript-eslint, however, does provide many type-aware lint rules which consume type information to provide deeper and more powerful lint rules. I would suggest having a read of https://typescript-eslint.io/getting-started/typed-linting, and you can see all of the rules that consume type information here.

so it's not like we could easily replace TypeScript with something else

Writing a parser that produces an identical tree isn't particularly difficult (and is what is basically being proposed as the alternative approach, right?). You're saying you can't write that parser later if you don't write a parser now? I'm not following the reasoning.

Writing a parser that produces an identical tree isn't particularly difficult

Isn't it? My impression is that all JS parsers contain thousands of lines of hand-written code (Acorn does).

and is what is basically being proposed as the alternative approach, right?

Not really an alternative, more like an addition. Existing TS parsers for ESLint should continue to work. What I think we need is an alternative AST specification because we would like to keep rules functioning even if TypeScript decides to change the AST format in a future release.

You're saying you can't write that parser later if you don't write a parser now? I'm not following the reasoning.

Sure, we could definitely write a TS parser later while using @typescript-eslint/parser as a reference to update the built-in rules logic. As I said, I don't think the parser should be a blocker for the rest of the work. This discussion is actually about supporting TypeScript as a language for ESLint, I'm surprised to see the focus shifted on the parser.

What I think we need is an alternative AST specification because we would like to keep rules functioning even if TypeScript decides to change the AST format in a future release.

The typescript-eslint AST spec is exactly that.
We are not tied to TS's AST - we are an extension to the ESTree AST spec.

If you inspect typescript's AST you'll see how vastly different the two structures are.
You can use our playground to see both ASTs (and the types, and the scope analysis).
https://typescript-eslint.io/play/

With each TS release typescript-eslint updates to handle any changes TS made to its APIs or AST and we do so without also introducing breaking changes to our AST representation. We also do so whilst maintaining backwards compatibility with older TS versions. Here is our AST versioning policy

We only make breaking changes to the AST in major versions and usually the process for those is we deprecate them in one major release and then remove them in the next (to give the ecosystem time to update and support the new structure).

Similarly we only drop support for TS versions in major releases. We generally keep in sync with DefinitelyTyped's support. Here is our TS support policy

Thanks for the summary and the policy links @bradzacher. From my side I don't see any problems with using @typescript-eslint/parser and recommend its usage if the parser specifics like the AST format can be defined by the ESLint team. I'm not sure what TypeScript versions we would like to support at this point - for reference, ESLint supports all ECMAScript versions from 3 to latest - but that's part of the discussion.

@RyanCavanaugh I'm talking about the difference between planned work and unplanned work. Planning to create a parser and keeping it up to date ahead of time is a wholly different process than an emergency "oh shit we need a parser" process. We already have experience with the latter when Esprima silently died, and that's not something I'm anxious to repeat.

I don't see any reason why they would differ.

Is there a difference in typescript-eslint's parsing performance when type-aware linting is enabled vs when it is not enabled?

Yes there is.
When not in type-aware mode we just parse files as single-files. No type information - just the AST.

In this mode it is no different to espree or any other parser, aside from being backed by TS's parser.

I don't think the goal is to be faster than tsc or typescript-eslint, but rather, to have a consistent performance that is on par with typescript-eslint without a dependency on tsc.