Request for information (documentation): intended architecture

[JoshuaKGoldberg]

I'd like to get involved with this rewrite, but it's hard without understanding how it's meant to work. At least:

• What are the intended packages to be built, and how do they interact?
• What is the vision for each package's rough APIs?
• What is the vision for the end-user experience?

For example, I had a hard time having any opinions on #62 because:

• It's not clear what's meant to go in @eslint/core
• It's not clear what packages are meant to consume those things
• It's not clear long-term what the vision is for how this will supersede and/or work with @types/eslint

For reference, #52 was a nice start for some decisions - but doesn't touch much on larger architectures.

[nzakas]

Yeah, the short answer to all of your questions: we just really don't know yet. We're still working hard on getting people migrated to v9, updating how config resolution works, and implementing language plugins. The majority of the rewrite work, including thinking through architecture and long-term vision, will happen after that work is completed.

What we know at a high level: we want a runtime-agnostic core (@eslint/core) that publishes its own types. (Indeed, every package in this repo will publish its own types so we can stop depending on random people creating random types for us in DefinitelyTyped.) Because languages are a new feature, it seemed like a good idea to define our own types for that up front and them use them going forward. Thus, @eslint/core will start by just exporting types.

There will then likely be a @eslint/node and @eslint/browser that are verified and tested on those runtimes.

That's about all we got right now.

[nzakas]

As a result of today's TSC meeting, we came to a definitive conclusion on the types question:
#77