-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Description
ESLint version
HEAD
What problem do you want to solve?
While working on a new API design for the core, I've come across the situation where I'm not sure if the API I'm envisioning is practical or will work the way I expect. As such, it will be difficult to design an API from scratch without performing some implementation along the way...and I don't want to have to rewrite the core on my own in the process.
What do you think is the correct solution?
What I'd like to do is start refactoring the current core in a way that makes it easier to experiment with a new API. Specifically, to start pulling things out of Linter
and ESLint
and into their own classes. These don't necessarily have to be the final new core API, but it would at least give me an opportunity to explore everything the core is currently doing and see if I can start carving out smaller classes of functionality that will inform the new API.
Here are some of the pieces I have in mind:
- Extract parsing into a class
- Extract pre/postprocess into a class
- Extract rule context into a class
- Extract config normalization/validation into a class
- Extract ESQuery parsing into a class
- Consolidate config-related functionality
- Refactor source code traversal to allow for async traversal
- Replace
SafeEmitter
with an async-capable option
Participation
- I am willing to submit a pull request for this change.
Additional comments
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
Status