Converted npm-naming from TSLint to ESLint #681
Conversation
JoshuaKGoldberg
force-pushed
the
npm-naming
branch
from
cab8e89
to
0bfae60
Compare
JoshuaKGoldberg
changed the title
| let parent = path.dirname(fileName); | ||
| // May be a directory for an older version, e.g. `v0`. | ||
| // Note a types redirect `foo/ts3.1` should not have its own header. | ||
| if (allowNested && /^v(0\.)?\d+$/.test(path.basename(parent))) { |
There was a problem hiding this comment.
Maybe not for this PR, but I suspect that it will be easier to just use the new util I have above which gives the package dir for any file within the workspace (or undefined if not). Then we don't need to use regexes, allowNested, etc.
There was a problem hiding this comment.
I'm not quite confident enough in this repo to do that myself, but I do like the idea. 🙂
|
One thing we'll need to do here is filter it out of the preset; after #843, what we'll do is have it disabled by default in the preset, then override it on when running eslint. That way, the editor doesn't run it but dtslint does (just like how I override ExpectType with the list of TS versions to test). |
|
|
||
| exports[`plugin should have the expected exports 1`] = ` | ||
| { | ||
| "configs": { |
There was a problem hiding this comment.
This is a new snapshot I added to the PR to baseline our exported plugin; you'll see in the commit that filtered out npm-naming that it was removed (but the rule remained as a rule).
|
This PR should now be cleaned up and ready for review/merge (plus a change in DT itself to move the linting over). |
|
Running locally, I get: |
|
Oh npm $ npm info alpha-shape --json --silent versions dist-tags
{
"versions": "1.0.0",
"dist-tags": {
"latest": "1.0.0"
}
} |
| @@ -27,8 +27,8 @@ export async function lint( | |||
| // TODO: To remove tslint, replace this with a ts.createProgram (probably) | |||
| const lintProgram = Linter.createProgram(tsconfigPath); | |||
There was a problem hiding this comment.
We only use this program to build a list of files; not for this PR, but we're going to have to remove this when we remove tslint so I expect that we will just ask eslint to run on all non-ignored files (which is a lot better than having to find a list of all files here).
There was a problem hiding this comment.
That being said, since we run type-using rules and also use project=true, it's likely that people will have random files that aren't in the program that may break via ts-eslint complaining about not being in a program, or via new lints that were previously uncaught.
There was a problem hiding this comment.
Cost reduction: Linter.createProgram is a standalone public static, so an equivalent could always be re-written.
There was a problem hiding this comment.
Probably, yeah, though it seems a bit overkill to build a Program to only use it to list files!
Continues #648 by migrating
npm-namingfrom TSLint to ESLint....mostly. This removes the dependency onI ended up overhauling this to go all the way to using just ESLint/ESTree. ✔️tslintbut still operates on the TS tree instead of TSESTree tree. I ran out of energy overhauling these more TypeScript-intertwined rules... is this ok as an intermediary step?Also updates the
dts-criticscript's hardcoded naming rule modifiers to operate on.eslintrc.jsoninstead oftslint.json.