I don't want to muddy up the AST with more nonstandard properties (I'd love to actually get rid of parent), but that doesn't mean we can't think of other ways to traverse the AST.

I'm not sure that this is a good decision as I've yet to see any library that recently released that didn't eventually end up doing a TS rewrite.

That's a good point. If every other tool rewrite last years is done in TypeScript (and not JavaScript), maybe there's a reason and rationale behind this?

Mixing types with JS makes it quite unreadable and it only gets worse as you go into complex logic.

I said the same thing until a year ago. Then someone finally convinced me to give TypeScript a serious a try. It turns out the type annotations are not nearly as noisy as I expected. Give it a shot!

I don't think the differences are as drastic as some describe, having contributed to both TS and JS libraries. I've had meh experiences with both. One one hand, TS packages always have type-checking which is great. JS ones, have no expectation of this. But we shouldn't equally compare the worst of JS packages with the best of TS. I mostly resolved to JS+JSDocs but have two key enforcements that I don't code without:

• jsdoc/require-jsdoc: All functions should have JSDocs for the purpose of documentation. Regardless of what language you write there should be an area for better explaining function and parameters. I've noticed that enforcing this rule improves developers putting useful notes and examples. This is applicable to TS code or JS code, but if you're writing in TS and have to put documentation, then you're now writing each function parameter twice. Since Typescript itself does not read JSDocs (odd decision), it means you have to write the type in the function as well as the JSDoc. With JS, because of this enforcement, it ends up being less code to write.

• "noImplicitAny": true. The lack of this option is probably the most frustrating aspect of working with JS packages. It's amazing how sometimes just enabling this rule in a repo will expose thousands of TS errors. It's just not a sound development decision to not have this enabled. I can imagine a lot of other's bad experiences also stem from this.

There's obvious some more you can add on, but I'd worry about a JS project without these. If you're not keen on enforcing documentation, (first of all, why?), now you're writing more JS code and wrapping everything in JSDocs. Just write it in TS. Save your sanity.

But I will say one of the major frustrations of working with importing packages that are in TS is the recompilation issues stemming around distribution and decoupling. This is clearly subjective, and maybe it's more VSCode's fault, but it's a very common source of frustration when I'm trying to work with a package and need to figure out what's going on behind the scenes. VSCode will send me to a typings file which tells me very little about what the function is doing. Trying to get to the source will throw me to a recompilation of the source, which again, forces me to search through source code to figure out what I'm actually calling. If it's compiled to CJS, it points me to not the original source code, but the compiled one with plenty of require remappings . If it's ESM, it'll be the JS code without any typings over JSDocs, so everything will appear in source as any. That means you'll have to jump between the code and typings file to understand, or now leave your environment to GitHub to read the real source. With JS+JSDocs, it's all in one location (for better or for worse). I can see all the types, the code and documentation with one keyboard shortcut.

That said there are some things you must acknowledge with JS+JSDocs:

• Type casting is very verbose. While one of the benefits is all runtime code is clearly abstracted from typing (because they're in comments), being able to use as is just way shorter. I'll admit, I'm sometimes just lazy and call ts-ignore instead of trying to wrangle the syntax.

• You can't reliably write real JSDocs. There's so much that TS has going for it that you will end up adopting TS specific things like Partial<T> and extends. These don't translate to other packages if you feel like you're going, say, use JSDocs to build documentation. If you want to multi-line @typedef, that's also TS specific. That also goes both ways, TS doesn't 100% parse JSDocs. @yield is still unsupported. Also you can't escape variable names like x5t#S256 in JOSE.

• Typescript will not always automatically parse JSDocs. I'm not sure if there's something missing in a configuration somewhere, but I've worked with JS+JSDocs projects that end up with unresolved types when you inspect the source externally. I don't know if there's a way to fix this, but it's something common I've seen. VSCode doesn't show the @example tooltips either sometimes. If I had to guess, generated d.ts files strip documentation and override source .js files. Again, might be a packaging mistake.

Likewise, there are some common misconceptions related to JSDocs that need to be clarified:

• You can import a d.ts from any JS file. While the JSDocs is limited, you can easily spin up a d.ts file and write a type, then import it in JS. I've needed to do this only a handful of times, but it works just fine. All instances where I had to do this related to recursive types (eg: export type TupleTree<T> = Iterable<[T, T|TupleTree<T>]>;). I like keeping my types next to code, but if you want to build an entire separate, d.ts file you can. Also, you don't need to call @typedef {import... if it's a pure definition file. Typescript will pick up all the types automatically.

• You do not have to set the type on most variables. It's actually rare to have to call @type inside a function if you enforce JSDocs. Lazy initialization (let foo;) sometimes need it, but TS will infer the type automatically in most cases. Same also applies with @return. no-implicit-any makes writing that JSDoc line optional since TS can infer it. I only add it when I'm being strict.

For real world examples that I've worked with, I can list three similar projects: moment, date-fns, and date-fns-tz. moment being a JS+Typings sends me to a one-liner require when trying to inspect source. I have to go to the GitHub page. date-fns is a TS project and will send me to a compiled JS file, and while it's more understandable than moment's, it's still mangled. date-fns-tz is a JS+JSDocs and trying to work with it is clear and simple. All the source file is untouched, and I never have to look beyond my node_modules structure.

As with anything, there are pros and cons, but you have to decide what works best for you, and what you are willing to maintain. There's no point in frustrating yourself on something because you will eventually stop caring about supporting. Whatever you chose, note the cons and reach out for help if you can't find a way to workaround them. Also, know your audience. Who is going to be inspecting your source? Who will be contributing code? You, at the same time, don't want to something hard to work with for your target audience.

I am a maintainer on a large project which initially adopted JSDoc + tsc, until the codebase was fully typed, but has recently started switching to native TS. Our reasons for doing so were:

1. Friendliness to new contributors. Most documentation about how to specify types that tsc understands use native TS syntax, and figuring out how to express the same thing with the JSDoc syntax adds an extra layer of indirection. Ironically this was one of the reasons for using JSDoc initially.
2. Better tooling for native TS syntax than the equivalent JSDoc. Prettier for example can format TS out of the box, but ignores JSDoc.
3. The issue mentioned in the previous comment about certain constructs being rather verbose, mainly type-casting

I do think there is significant value in having code which can be run directly in the browser or Node without any processing though. For build tools etc. which run in Node, we still use JSDoc.

Mixing types with JS makes it quite unreadable and it only gets worse as you go into complex logic.

I said the same thing until a year ago. Then someone finally convinced me to give TypeScript a serious a try. It turns out the type annotations are not nearly as noisy as I expected. Give it a shot!

I don't really have a choice of the codebase I have to deal with. So I gave TS more than a try. Some folks are going religious about it, but at the end of day, your perceptions and experience belong to you. There is no doubt in my mind that I prefer to read code with JSDoc above the function code, than TS annotations mixed within the function code.

In the same way, I am not a fan of CSS-in-JS libraries like emotion, because all these styles coding make the component logic and the overall picture harder to grab. For that reason I prefer Svelte/Vue (single-file components or not) to React. There too, I am sure you will find a crowd starting a fight out of their own perceptions and experience over which is best for what.

This is a not a judgement over the value added of typing. I wrote some Elm code in some past projects and that was the most delightful front-end experience I ever had. They got that right. The type system is not as good as Haskell, but it is also far simpler, far more readable, and type annotations are, like in Haskell, separated from code. Elm is at another balance point between full-fledged type systems (which can be used to prove program correctness like Coq) and the complete absence of type system.

When we don't have a choice, we do what we must do. I'll live with TS. I am paid to do so and I gladly oblige. But when I have a choice, JSDocs works for me. Not as expressive as but expressive enough. Yet another balance point. To be used in conjunction with a good testing strategy (type safety is not safety).

@clshortfuse I enjoyed reading the summary of your experiences with very concrete examples - that is helpful. More importantly, I hadn't thought about the impact on the maintainer who has to make the choice. It is true that the two/three people who contributes 90% of the code (not unusual in OSS project) should give themselves a greater say in what technology to use. You said it right, you also need to listen to your target audience. But in the end the ones who will be mostly working the codebase are the maintainers. So there again it is a balance to find between conflicting needs.

Providing types in a package is a mistake; it conflates semver of the types with semver of the actual API.

Is there any way you can elaborate on this being an issue?

In practice, haven't seen any real issue here. When the types update, it uncommon for it not to be a signal of API changes as well.

@nzakas there are many reasons keeping types in sync is a moving target - especially that every TS minor release is likely to contain breaking changes. Also, the TS team keeps DT types up to date for you (syntax-wise, not API-wise, ofc), so that's an added bonus.

So are you talking about TS syntax changes?

I generate types at build times for a lot of my personal projects, so I’m just not clear on what the dangers are that you’re referring too.

Yes, I’m talking about changes in the build output, and the runtime behavior, and also in the type system itself. eslint will need to maintain compatibility with a lot of TS versions to avoid frequent majors, and that is very difficult to do (which is why the TS core team takes it upon themselves in DT, because it’s too hard for everyone else to figure out)

I would like to refute your assertion that it's difficult to support TS versions.

TypeScript-ESLint has been shipping our own types for ESLint for years whilst also internally keeping updated to the latest TS version.

We haven't bumped our minimum TS version in a long time - currently have support for as far back as TS 3.3 (released FOUR years ago).

TS releases are not an issue to support into the past. There are tools like downlevel-dts which you use to allow you to write the latest syntax and ship support for older versions along side new syntax (via package.json typeVersions).

We are about to bump our minimum TS version in our next major. Though not because of type pains! Instead because we are built directly on top of TS - so by bumping the minimum we can delete some logic we maintained for old versions of their parser tooling to reduce some maintenance burden.

Additionally TS compilation over versions is stable, or changes are explicitly called out in released. I don't remember there being one in a while though.
Regardless we have never had a breakage in our project due to a runtime change from a build output change.

Somehow I also feel like Rust could be the better option in the long run. It's just really early days but I already see that many tools are moving to Rust for performance reasons.

Beside that: ESLint, Rome and Prettier always had one big issue in my opinion => They try to be JS/TS first.
At work we have e.g. projects using https://github.com/HubSpot/prettier-maven-plugin
And yes, under the hood it uses prettier https://github.com/jhipster/prettier-java/blob/2e0e0da2a288068c91d8f4c6133eedc4b7ce23ca/packages/prettier-plugin-java/package.json#L14
But Prettier ships with many stuff for JS out of the box which is just not used at the end, as there is no single line of JS code in our project(s).
And I highly assume ESLint and Rome is like currently the same.

I would love to use one single tool to lint everything but this tool only use what it needs and also is freaking fast. Not 20ms per file but 20µs per file would be a huge benefit

Another point of moving to Rust would be that slowly (at first) the whole parser / AST generators can be written in Rust which effects the whole ecosystem in terms of speed in the long run.

I had a thought while reading this thread and wanted to introduce an option:

This may be one of those situations where there is an opportunity to unite a community by saying the next ESLint version will be Rome (in a sense). Basically: join Rome.

Rome may not be perfect, or may have some concepts you would not agree with, but I feel that could be overlooked in preference of the "greater good". I believe if ESLint puts its backing behind Rome, it may start a domino effect of movement.

What does that get the community?

• Easier decision making when starting a project
• Easier decision making on API's / config
• Easier movement for community (lets say: JS incorporates typescript as first class citizen. Single project community can rally around and make sure migrates to that new language feature)
• Combining of talents: Rome is already written in rust, and would mean less barrier to considering that option

Mostly the unification of the community is why I feel this may be a good idea. Intirested in your thoughts!

I often thought about this myself, but I have my issues with Rome and their maintainer(s).
I already asked multiple times (on bird-site) if they could guide me the way of how to provide e.g. a pug plugin, but they totally ignored me.
I also looked into their docs and it feels like they want to rule everything. Also a goal of Rome is to format, lint and even bundle code but mainly JS/TS in the first place.
So also this doesn't match with my dream-linter tool.
I just want one linting tool that can lint everything on demand and only what I tell it to lint and with my configuration. Not formatting and not bundling. I already have other tools for formatting and bundling.

Thanks for the insights. I'm very well aware of Rome and I don't see ESLint and Rome being a good fit to work together. Rome is all-Rust, which gives it speed but also limits the extensibility. We want to continue to support the existing (large) ESLint ecosystem, which means some parts will need to still be written in JavaScript. Plus, I don't think we want to rely on a profit-seeking startup vs. having a community-driven project like ESLint. What happens if the startup fails?

On the Rust side, I think we will definitely look at rewriting parts of ESLint in Rust. We have some folks looking at that right now. Will we go all the way with Rust? I don't think so. I just don't think we can do that without instantly making all the custom rules and plugins people have made obsolete, and then it's like starting up any other random project where people will need to get things set up again.

Never say never, but that's my current thinking. There will be RFCs when we have some more definitive ideas.

Rome is VC-funded if I understood well. While it sounds great to join effort, as I read in a previous post. That means that down the road the direction and governance of the project will be influenced in different ways that the current maintainers may wish.

Rust is great and fast, and also as of today, it carries even more cognitive overhead when it comes to contributing... For a project like eslint where contributed plugins make a good part of its value, Rust is a suboptimal choice I think.

I would very much suggest unifying the parser, so that it doesn’t matter if someone uses JavaScript or TypeScript. They’ll use the same parser and the same rules.

In other words: TypeScript support should be first class, or it never gets the ecosystem buy-in to be truly frictionless, and you’ll be back at the situation of today.

As a user of TypeScript and ESLint, it would be nice not to have to add additional TypeScript-specific packages from a different project, in order to use ESLint with TypeScript. Aside from requiring extra dependencies and configuration, @typescript-eslint appears to have some philosophical differences from ESLint in that its "recommended" set of lints IMO go beyond finding issues that are highly likely to lead to errors and into more subjective territory.

Anecdotally I personally don't recall seeing a non-type-only package major bump purely for type changes unless they're major bumps.
It's rare that you are able to make breaking changes to your type API surface without also making breaking changes to your runtime API surface as they're usually pretty tightly coupled.

I’ve seen it frequently - just renaming an exported argument type, for example - which has no direct JS representation - would cause this.

I still feel that's more of an issue with how the specific package is maintained, rather than a disadvantage to bundling types. As mentioned elsewhere in this thread, there are already statically typed languages that have in depth support for packages and updates.

@willster277 bumping the major version because you renamed a type is correct, but is a very high cost to impose on normal JavaScript consumers who have to read the changelog to discover that they're not actually affected at all.

This is given without much elaboration, can you elaborate on how this is a high cost? Also, is it actually a requirement to bump major due to types?

I just haven't seen this as an issue in practice, even at large companies (bigger than Airbnb even!) I've worked at down to smaller ones.

@ScottAwesome I agree. I've never found myself in a situation where I need to rename a type and make a breaking change.
Even if I had, I'd put it on the backlog until there were enough other "we really want to break this" things to warrant a breaking change.

The blindingly obvious thing to do is to do the exact same thing we do when we break our Javacript.

Before:

type OldNameIDontLike = /* ... */;

After:

/**
 * @deprecated use {@link NewName} instead
 */
 type OldNameIDontLike = NewName;
 
 /**
 * @since vX.Y.Z - replaces `OldNameIDontLike`
 */
type NewName = /* ... */;

If the content of the type has a breaking change, then simply keep the old definition under @deprecated and make the breaking change to the content within NewName.

Changes with Types work the exact same way and pose the exact same issues and have the exact same mitigations as changes with functional JS, with the key difference being the changes with Types are almost always a side effect of a change with functional JS, meaning you would be doing this regardless of your use of TypeScript.

Passing this to the parser is actually what we've been off-and-on talking about sending as an RFC to ESLint for some time! It's what I've been planning on working on once our v6 is out the door.

@nzakas absolutely that would help; as long as individual rules could register their own listeners. If the identify of context.session remained consistent, that could be a WeakMap key for anything that needs caching per-session :-)

@bradzacher @JoshuaKGoldberg for clarification: you’re saying the session info is needed not just in rules and plugins, but also in the parser? Can you explain more about that?

@ljharb ah that’s interesting! I hadn’t thought about exposing these events within rules. Can you explain more about how you think that would work? My initial thought was that plugin-level hooks would the best use but definitely want to hear more.

@nzakas essentially, let's say I have 20 rules in the import plugin, but only 12 of them need the cached dependency graph. If the other 8 are enabled, the dep graph shouldn't be gathered - but if any of those 12 are, then prior to any rule running (and the timing info for any rule begun to be measured), i'd want a "pre-lint" step where i could gather the dep graph and cache it, and then all of the rules that need it would have it available.

Even better is if all the rules that don't need this cache could run first - ideally in parallel - so that rules aren't unnecessarily delayed.

The reason to use a per-session cache is long-running use cases like eslint_d, or in an editor, or jest-eslint-runner, etc.

for clarification: you’re saying the session info is needed not just in rules and plugins, but also in the parser? Can you explain more about that?

yes - type information is generated in the parser.
the workflow is essentially:

1. eslint asks @typescript-eslint/parser to parse
2. @typescript-eslint/parser uses @typescript-eslint/typescript-estree under the hood
3. @typescript-eslint/typescript-estree inspects the parserOptions to determine whether or not type-aware linting was requested (specifically looking for parserOptions.project to be set)
   • if set, @typescript-eslint/typescript-estree coordinates TS to create a ts.Program - the data structure which includes all information about a tsconfig.json and from which type information can be interrogated. The program is returned as part of the parser services.
   • if not set, @typescript-eslint/typescript-estree just uses TS to parse the singular file and nothing more.
4. ESLint coordinates the lint rules
5. If a rule wants to use type information it accesses the ts.Program from the parser services, and consumes them (details not important for this discussion)

Our requirement isn't at the plugin level - lint rules just use the generated data structure.
Our requirement is at the parser level where we do all of the work up-front to create the backing data structures to power type-aware linting.

I would love to see markdown support. I would be a good complement to prettier. See the rules in https://github.com/DavidAnson/markdownlint.

eslint-plugin-markdown

This seems to lint JavaScript inside markdown. I want to lint markdown.

It's possible to support any language with ESLint right now (eg eslint-plugin-relay or eslint-plugin-graphql lint graphql fragments and .graphql files), there are just certain constraints the parsers need to work within to produce an AST that ESLint won't crash on.

@oliviertassinari there are things like markdown-eslint-parser and eslint-plugin-md but as you can see from the download counts - in general people will just get behind tools that are built for purpose (like markdownlint or remarklint).

To clarify: a lot of these other tools copy ESLint mechanisms to bootstrap their own linting. The idea here is to create a core that is general purpose both to make it less difficult for things like graphql-eslint to plug in and also to allow folks to more easily create standalone tools like markdownlint that currently need to reimplement all the boring stuff the ESLint core has.

Done!

But with Rust's ability to call out to JavaScript (as mentioned in the OP), wouldn't there still be the option to do the same thing in JavaScript?

It will still be "not JS" because of the extra JSDoc syntax that you'll be introducing (which is worse than TypeScript, having tried this out).

So better to introduce a new language that has a better syntax, more features and a larger developer community (TypeScript) than one that is worse on all of those metrics (JSDoc)

@JoshuaKGoldberg

So just confirming - although ESLint will not be JS-specific, the idea is that it still is a JS-first tool? E.g. you might be able to use it for non-JS code such as Markdown or even any arbitrary language, but the focus will still be on JS/TS & adjacent web languages?

Sort of. The idea is that ESLint will be targeted primarily at the web development ecosystem. The ESLint team will still maintain JS-specific functionality and possibly some others (JSON seems like an obvious one?). JS still seems like the best language for plugins and custom rules, so likely that the core will remain written in JS. But we really want to encourage others to create plugins for other related languages like CSS, Markdown, TOML, YAML...anything that is typically found in web development.

I'm under the impression that if someone wanted to write a plugin in JS and have it be called by Rust, they could.

Yes, this is possible, however, you pay a penalty every time you cross over the Rust-JS boundary. If you think about how rules work, where you create an object that then visits nodes in the AST, it's not a very clear line between Rust and JS. Let's say the AST lives in Rust, that means for every visitor function we call, we'd end up serializing the AST node from Rust to pass into JS. That's some non-trivial overhead. So, that likely means the AST needs to stay in JS to avoid paying that cost. And if the AST stays in JS, there are likely other things that need to stay in JS to avoid crossing the boundary multiple times. So, short answer: this is more complex than it seems. If ESLint plugins just provided data without functionality, we would have more options, but as it stands, a complete Rust rewrite seems not to be the best approach. That said, using Rust and embedding Deno allows us to start with most of the core in JS and then to slowly try to replace pieces with Rust to see what will work and what the performance implications are.

And as @ljharb mentioned, a complete switch to Rust would limit contributions. Having spent the past month learning Rust, I can tell you it is very intimidating and often very frustrating. Given that we are targeting the webdev ecosystem, JavaScript is a much softer landing point for contributions.

Yes, this is possible, however, you pay a penalty every time you cross over the Rust-JS boundary.

So, that likely means the AST needs to stay in JS to avoid paying that cost.

I agree with these statements but it makes me wonder, if the parts that handle the AST (by that I understand parsing and linting). What are the other pieces that could be written in Rust and would not have to pay this boundary-crossing cost ?

I've seen many projects talk about having parts using Rust, other languages, either binaries or WASM that were disappointed of the performance wins from the native parts as they were offset by the serialization/deserialization cost when crossing the boundaries.

Here is for example the discussions that happened for SWC:

• a first plugin implementation : Javascript plugin swc-project/swc#471 (was removed since but can't find the related PR)
• a discussion to add something new for V2 : [Meta] Plugin system for 2.0 swc-project/swc#2635 (didn't land, went for WASM plugins instead)

On another note, Parcel made an interesting use of SharedArrayBuffers to be able to share maps across threads, since SharedArrayBuffers are also available in Rust, I wonder if that could help with serialization/deserialization issues (disclaimer: I don't have any significant experience myself with WASM or Rust)
parcel-bundler/parcel#6922

It’s not about avoiding the boundary cost, but minimizing it. For instance, a lot of the CLI bootstrapping can easily be done in Rust and be a lot faster than in JS: searching the file system, reading files, etc. Then we can just pass those strings into JS to work with.

There are a lot of possibilities and a lot of existing approaches to review. Right now we are just capturing ideas, so I can’t be more specific than that.

honestly - the type annotations proposal is... weird. It's just a proposal for a sort-of-structured place in JS code where type annotations can go, but there's no spec for even basic validation (like, say, track that types reference types, or names reference things that exist), let alone type validation.
So ESLint would have to design, spec and build an entire system around that complexity.

It's also a long, long way off (if it ever actually lands).

I think that making the type-information portion pluggable is a great idea because it means ESLint is agnostic of the type-system, but provides a consistent API that future parsers could build within to allow plugins to opaquely consume type information.
Again though it would require very careful design to ensure that it's providing a truly system-agnostic API.

Yes, my intent was to make type-awareness as generic as possible and not specifically tied to TypeScript. Allowing it to be pluggable would make a lot of sense.

My feeling is that there will likely be some tools developed with non-TypeScript type awareness and it would be good to be able to hook that in. I could see a situation where the core JS plugin has a default type-aware functionality (using JSDoc, most likely) that could be swapped out.

Amusingly, JSDoc types already exist in TypeScript. There might be a lot of time saved by going with TypeScript as a default provider for that system - both in developing the system, and for users needing to set it up.

Yup, that was my intent. But to your other point, figuring out a way to still make that plug gable would be important.

I've been doing pure JS with JSDocs for years now and pretty much any project I do have both eslint-plugin-jsdoc typescript-eslint. But I will say that JSDocs syntax isn't the same as what Typescript reads. I have to disable jsdoc/valid-types because of things not in JSDocs like recursion, Typescript specific interfaces (Partial<T>) and extends. Not having to use @typescript-eslint/parser would be nice.

Once the new config system is in place, we are going to stick with it. You an always specify an alternate config file location using -c on the command line if you want to move your config file elsewhere.

Yes, performance is a main driver of this rewrite.

Already mentioned above, but TypeScript is off the table. ESLint needs to work on vanilla JS out of the box, and to do a good job, we need to dogfood ESLint on itself. We'll leave TypeScript-specific functionality to the typescript-eslint folks.

@nzakas obviously you get the ultimate decision on this but for the tool to remain popular and relevant you need to listen to the community. You're almost universally being told TS is the way to do this correctly, please don't dismiss it because it doesn't conform to your original plan or some preconceived idea.

I can't think of any major project that I'm aware of that has switched to typescript and regretted it or switched back. Even Jest ditched Flow for typings because typescript is just that much better for community contributions.

Thanks, we can consider this. The big problem we have is compatibility -- if we don't want to force everyone rewrite their existing rules to use a new schema format (which we don't), we have limited options. This is also why we never upgraded ajv once the next major version came out -- it had too many breaking changes that would have caused a headache for the ecosystem.

As already mentioned in several threads above, TypeScript is off the table. I'm aware of the tradeoffs but we need to dogfood ESLint in vanilla JS.

Just to throw my own two cents, I think the dogfooding argument should actually go towards using TS: while ESLint works very well for raw JS, the way it works for TS isn't as smooth. I would imagine if ESLint was written in TS (and thus was dogfooding it), the integration would be much better (at no cost for JS, I'd also imagine, with JS being essentially a subset of TS).

And I'd also add on top of dogfooding TS, you would get two parsers for the price of one by using the TS parser, as an added bonus there is the reading of JSDoc by the TypeScript parser that could help add rules that understand types (which I seem to understand would be a goal of this rewrite)

@nzakas I already suggested (a bit above somewhere) that eslint should not support first class JS linting but treat it as a plugin for eslint like every other language out there
I have all my projects in TypeScript and even we use prettier for some Java only projects. In both cases we dont need the JS specific overhead eslint comes with.

Instead of dogfooding eslint core with it's own source, the eslint-plugin-javascript should get dogfooded with javascript files in its test-suite!

So having some notion of "parser-informed bucketing" would be really good for the future state of eslint.

Do you have an idea of what this might look like?

If we could hint to eslint that we'd prefer if the files are linted in a certain order such that each project is linted to completion before starting on the next project.

There’s an interesting tension here — ESLint currently works on files, not projects. If ESLint gets a list of files to lint, what would happen after that? Pass that to you for you to further dig into the file system? And what about the browser playground? Without a file system, what would change?

Without a file system then you're just working in a single-file world. It's entirely possible to mock out the FS and have everything still work as intended. EG our playground (https://typescript-eslint.io/play/) is fully set-up for type-aware linting. You could easily do a completely virtual filesystem as well (which is how a lot of browser-based IDE environments work with TS).

the TS team even has a package to make this easy to do (https://www.npmjs.com/package/@typescript/vfs)

In terms of what I'd expect - ESLint works up-front to determine the entire set of files to be linted, then it sends them to the parser for "bucketing". The parser does whatever work it needs to do to determine the best buckets for the set of files.
For TS it would be a manner of us getting the list of tsconfigs from the parser options, then interrogating the configs to find out what files they contain, and then bucketing files around those lists. In a nutshell we'd want to ensure that each tsconfig is included in just one thread to avoid duplication and wastage.

Thanks! I’m afraid we also don’t have the bandwidth to maintain a separate project.

I meant handing it off to the eslint team completely

So what I'm trying to say here is that it would be nice if the new version of eslint allowed:

• freeing resources no longer needed because all related files have been processed (eg. A ts.program)
• have some way to cache/persist/share session data across multiple processes