Support for mixed JS and TS codebases - do not lint JS files #109
Comments
|
by default eslint lint all provided files with all rules, you should use overrides if don't want specific files to be linted by some of rules you can also set example of eslint config with overrides: |
|
Hi, I can do that, however, since I am asking, wouldn't it make more sense for this plugin to just ignore plain old js files? TypeScript does the same thing. (unless called with |
|
Seems like it might make sense for us to limit some of the rules in the recommended config. |
|
We had a similar discussion for the recent babel-eslint changes (see babel/babel-eslint#738) about how to handle files that aren't being transformed by Babel. What we ended up deciding on was the following behavior:
Here's the corresponding PR: babel/babel-eslint#743 It could make sense to do something similar here and have an opt-out flag that throws an error (and so would short-circuit this flow before it can run the rules) when parsing is done on a file that doesn't end in |
|
Mixed codebases has come up a number of times, but the answer we always arrive at is the same: if you have a mixed codebase, then it's up to you to decide where your boundaries are, and what rules you apply to what files. Unless I'm mistaken - we can't apply overrides in the recommended config, because of the precedence of how overrides work (they override the base That being said, we could consider exposing a babel-eslint is different IMO because it requires the babel config, and will crash if misconfigured (i.e. babel parsing a flow file without flow config will not work). (correct me if I'm wrong there). Our parser requires zero typescript config to work on a As an aside - in this instance of a gulpfile, you should actually be able to write it as a ts file! (https://gulpjs.com/docs/en/getting-started/javascript-and-gulpfiles) |
|
An example I like to think of is the rule But what happens when within my project, I decide to write a cli build tool which needs access to It's not a bug in the config, or a bug in the rule, it's a problem in my specific setup - eslint or the config doesn't know, nor does it care that this new file is not run in the browser. Thus I have to modify my local config to suit my project's setup. |
|
The problem is that {
"extends": [
"plugin:@typescript-eslint/recommended",
// ...
],
// ...
},
"overrides": [
{
"files": ["*.js", "*.jsx"],
"rules": {
// "@typescript-eslint/...": "off",
}
}
]
}This is not ideal, because if the It would be nice if the rule would work with |
|
Another problem with current recommended config is the disabled rules in favor of the |
|
@markogresak can you provide example of issue with any rule for js files?
upgrade tool is nice idea |
|
@armano2 sorry, I messed up my configuration a bit wrong and got some problems related to my project and config, not the For the rules disabled in But I've noticed some issues with the config. The order of |
|
facing the same problem. |
|
@fatfatson ESLint already supports this. Please see https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns for more details. |
|
Also of note: ESLint also now supports nested |
|
This is actually huge!!!! |
@markogresak @fatfatson Turns out to have an equivalent Airbnb Typescript config is not straightforward, and yes, the ordering matters. See here for details. That was I am trying to achieve in my repo. |
|
even tho the solution suggested by @markogresak is a good one, it would be even better if somehow we could just turn off all @typescript-eslint rules like It's not very maintainable having to manually add the rules to this list. |
|
A potentially simpler way to do this would be to only turn on those rules for |
|
Woops, this issue fell through the cracks! It should have been closed a while ago. As @kaicataldo mentioned, you can accomplish this easily using eslint's In eslint v6, there was as whole lot more support added to extends, and it now works really intuitively. We're not going to bake in explicit file filters. In 2.0 we removed the instances of us doing this. |
|
For anyone who wants a working |
This makes it so that TypeScript rules are applied as a override on the glob '*.ts'. Seems to be a best practice to avoid duplicate or meaningless rules running on JS. See typescript-eslint/typescript-eslint#109 (comment).
Does this syntax work on eslint@5.x.x ? |
Nope, this is just a wish how we would like it to work |
Repro
JavaScript file (
gulpfile.js):{ "parser": "@typescript-eslint/parser", "parserOptions": { "ecmaVersion": 3 }, "env": { "browser": true }, "plugins": [ "@typescript-eslint" ], "extends": "plugin:@typescript-eslint/recommended" }Expected Result
I have a package with mostly TypeScript, but also a
gulpfile.js, which is plain old JavaScript. I was expecting this plugin to only lint the TypeScript filesActual Result
For the gulpfile:
error Require statement not part of import statement @typescript-eslint/no-var-requiresAdditional Info
I suppose this applies to any mixed codebase containing JS and TS together
Versions
@typescript-eslint/eslint-plugin1.0.0@typescript-eslint/parser1.0.0TypeScript3.2.4ESLint5.12.1node11.7.0npm6.6.0The text was updated successfully, but these errors were encountered: