Replies: 7 comments 12 replies
-
I'd define a package root as That would work automatically for single-project repos, and for monorepos, would mean that subprojects would use config to define "yes, look upwards", and then the root would automatically apply config to all the subprojects. Additionally, project awareness would mean that rules could be told, by eslint, what the root(s) are, so that it's clear when imports are reaching outside of the package or not. |
Beta Was this translation helpful? Give feedback.
-
I'll split my respond up over a few comments to aid with threading and responses.
For me a "project" is simply a distinct set of files in a given folder. It doesn't matter if those files are part of a shared dependency graph or anything like that - just that given a folder you can idempotently define Given that definition it's clear that a JS project is going to be a little different to a TS project, which is also going to be different to a project. TBH even frameworks can have different concepts of a project - Vue vs Angular vs React are all structured differently and might want to be grouped differently. Heck - individual repos might have a different concept of a project. |
Beta Was this translation helpful? Give feedback.
-
Given all that I would like it if ESLint would allow "plugins" to define the shape of a project. For typescript-eslint eslint (and likely most if not all TS repos - regardless of framework) we'd probably define one project per tsconfig plus one additional project for files not covered by a tsconfig. So I'd probably expect that eslint has no real idea of what a TS project is or looks like - just that each project is identified by a tsconfig path and each identifier resolves to a set of files. |
Beta Was this translation helpful? Give feedback.
-
With that in mind, we are very likely to allow having rules ask for additional files. One example we have is a documentation rule getting access to the changelog file to check that the current version (found in yet another file, So I definitely think having multi-file-aware rules is a move in the right direction, albeit a probably very complicated one. For Elm/ This unfortunately doesn't work for ESLint out of the box because the information is not anywhere. I would argue that there should be a field similar to Elm's The downside is that this only works for a single Elm project, as defined by the combination of files and dependencies listed in Similar to ESLint, the Currently, the rules that look at multiple files assume that they look at the entire project, which I believe is a reasonable premise for the tool. Say we're writing a rule that reports unused exports. If an exported function A side-effect of this is that a configuration can somewhat get tied to a project, but in practice it's not been much of a problem for The way that I would definitely encourage you to go through some of Here are off the top of my head a few things that we can do with the knowledge of multiple files: Be a lot more precise in targeting functions. If you have two imports Similarly, being able to determine whether a module has side-effects in its code can determine whether it is safe to remove an import or not. Being able to determine which functions/values/types are exported but unused For TS, being able to determine which enum values) are unused can help remove the unnecessary ones.
Reporting usages of functions from others modules that are marked as deprecated. More generally, being able to figure out any information about something that would be written where the thing is defined. I'm sorry if you were not asking about all these details. It was a bit unclear to me what you meant by "project" so I preferred adding more information that too little. |
Beta Was this translation helpful? Give feedback.
-
TBH by itself - nothing in particular. Right now eslint's file ordering is, for all intents and purposes, random. ESLint could lint a file from project A then a file from project B, them ten from project A, etc. As a plugin author - it's not an implementation detail we can rely on atm. If ESLint used the project grouping to order files - I.e. All files in a project are linted before the next project is linted (or in a multi-threaded world - one project per thread), then we can make decisions about how we manage memory. Right now we accumulate So if we (a) can tell ESLint the projects, (b) rely on the ordering of files, (c) know the set of files being linted and (d) know if we're in a single- or persistent-run then that enables a huge performance improvement for us - we can guarantee that there is exactly one Really, really big wins for us for the single-run scenario. Also worth noting (I touched on this earlier) - we define projects and these projects can be used to guide parallel linting. Without projects ESLint cannot do parallel type-aware linting efficiently because it will cause us to waste time duicating |
Beta Was this translation helpful? Give feedback.
-
I breifly touched on this in my other comment. IMO ESLint needs a new model for how it lints. Right now you pass ESLint a set of globs to resolve, a set of files to enumerate, and/or a set of specific files. From my experience for the most part repos will do a cli lint run in one of two ways:
I think the best future for ESLint is to simplify its CLI and just allow these two cases. Instead of relying on CLI args to drive the set of files - IMO the ESLint config should cover that. For example I'd expect that I could just run Given we're talking about the "project" concept here I'd also expect that eslint would accept a project ID which is resolved by a plugin to a set of files. For the "set of known paths" case I'd expect that ESLint would ask the plugin to group them into projects, then lint them like that. Eg |
Beta Was this translation helpful? Give feedback.
-
I like it. just a question: should it also add first-class monorepo support? nowadays I'm seeing mainly 2 ways to use eslint in a monorepo:
|
Beta Was this translation helpful? Give feedback.
-
As we are continuing to gather requirements for the next version of ESLint, one common question that keeps coming up is whether or not ESLint should be "project-aware." This is a bit of a difficult question to answer because there is no consistent definition of "project." TypeScript does have
tsconfig.json
that loosely defines a project, but what about regular JavaScript?Feedback Wanted
In this discussion, I'd like to get feedback on when it would be helpful for ESLint to know about more than one file at a time:
import
statements to know whether or not imports exist? Is there something else?We aren't talking deep implementation details or whether or not something is possible right now. What I'm hoping to get out of this is the wish list that everyone has in the back of their head. We are doing some serious rethinking of our APIs right now, so every seemingly outlandish wish is a possibility!
We want to make your life easier. Help us do it!
cc @bradzacher @ljharb @JoshuaKGoldberg @jfmengels
Beta Was this translation helpful? Give feedback.
All reactions