-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[2.4.0][Watch][Windows] ESLint doesn't exit after completing a cli lint #1079
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I am unable to repro this in our repo.
Questions:
as a temp workaround you can turn on the environment variable |
Could you try adding |
I also just tried to upgrade to node 12.12.0 but the problem persists.
set PARSER_NO_WATCH=true
npx eslint --cache --report-unused-disable-directives "./**/*.{js,jsx,ts,tsx}" does seem to resolve the problem. Could you elaborate on what this settings does or rather prevents from doing? |
Should I use |
This is the output of eslint when running with |
gah. windows. the one platform we don't have any coverage on. I'll have to dust off my windows laptop and do some investigation.
When you run eslint, typescript will tell us which folders it wants us to watch. 2.4.0 adds support for weak file watching - it attaches watchers to the folders typescript cares about, as well as the The environment variable does what it says on the tin - it turns off file watching within the parser (or more accurately typescript-eslint/packages/typescript-estree/src/tsconfig-parser.ts Lines 99 to 119 in 1918024
The problem we have is that eslint has no specific concept of a long running session, because it's intended to be pretty stateless.
Without, please.
Thank you! I'll investigate this as soon as I can. |
Thank you for the in-depth explanation all the good work! |
Should be pretty straightforward to add a Windows agent to the Azure Pipelines build, hopefully we can figure out a minimal repro to turn into a test |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I have a similar problem with macOS. |
Running into this as well. macOS. Running with For reference: .eslintrc.json {
"plugins": ["@typescript-eslint"],
"parser": "@typescript-eslint/parser",
"parserOptions": {
"project": "./tsconfig.eslint.json"
},
"extends": [
"eslint:recommended",
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended",
"plugin:@typescript-eslint/recommended-requiring-type-checking"
],
"env": {
"amd": true,
"browser": true,
"node": true
},
"rules": {
"prefer-const": ["warn", {
"destructuring": "all"
}],
"require-await": "off",
"@typescript-eslint/ban-ts-ignore": "warn",
"@typescript-eslint/explicit-function-return-type": "off",
"@typescript-eslint/interface-name-prefix": [
"error",
{
"prefixWithI": "always",
"allowUnderscorePrefix": false
}
],
"@typescript-eslint/member-delimiter-style": [
"error",
{
"multiline": {
"delimiter": "comma",
"requireLast": true
},
"singleline": {
"delimiter": "comma",
"requireLast": false
}
}
],
"@typescript-eslint/no-inferrable-types": "off",
"@typescript-eslint/require-await": "warn"
}
} tsconfig.eslint.json {
"extends": "./tsconfig",
"compilerOptions": {
"allowJs": true
},
"include": [
"src/**/*",
"tests/**/*",
"./*.js",
"./*.ts"
]
} tsconfig.json {
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"lib": [
"dom",
"dom.iterable",
"es2015"
],
"skipLibCheck": true,
"sourceMap": true,
"downlevelIteration": true,
"strict": true,
"allowSyntheticDefaultImports": true,
"esModuleInterop": true,
"inlineSources": true,
"rootDir": "src"
},
"include": [
"src/**/*"
],
"exclude": [
"dist",
"out"
]
} eslint |
Can confirm I am also facing this issue on MacOS Catalina (10.15), relevant config and versions are pretty much similar to those kalbert312. Passing NodeJS version: 12.12.0 |
Also locked @typescript-eslint/parser to 2.3.3 until typescript-eslint/typescript-eslint#1079 is fixed Signed-off-by: Jeroen Claassens <j.claassens@cgi.com>
Can confirm this issue on MacOS 10.14 and NodeJS 10.16.0. Rollback to 2.3.3 helps. |
If you're looking for a more robust way to disable watching, there is also a config you can add to your eslintrc - |
I've just landed #1106, and it will be deployed to the I'd appreciate if you could take a moment to test the canary tag on your codebases, and let me know if anything isn't working as expected for your real-world codebase. |
Hello, I'm running windows and I was also having issues where eslint wouldn't exit after execution (it would print the problems, warnings and errors and then just hang). adding --debug I didn't see anything abnormal. Adding the parserOptions: {noWatch: true} fixes the hanging issue and I would like to see if your commit(s) fixes the issue for me also. I'm not sure how to tell what commits went into a canary build though. Which canary build should I try? 2.4.1-alpha.8 or 2.4.1-alpha.9 or does it matter? |
The canary build is built off of master on every single commit. |
@bradzacher Just a quick update while still running. I've just upgraded to 2.5.0 and unfortunately things got worse for me. When running eslint with the |
Weird, I tested this extensively on CLI and I didn't see any perf regressions. Could you please do a run the debug flag |
My original run did actually end after 3016382ms and I will now run with |
I now just started running eslint again and it again runs as slow as before and should probably take about 1 hours to finish. The (intermediate) output looks as follows:
|
Windows is not case sensitive |
Windows is not case sensitive, so it needs the canonical path as cache key. |
Complete output |
You know what. I knew that. It's windows that's not case sensitive, and unix that is. I swear I saw typescript do some weird shit as well. Either way then, #1111 will fix this for you guys. |
Just merged #1111 - there will be a canary version in ~15 minutes. |
I've just tested with the canary version and do not see any changes or speed improvements. It is still about 100x slower then before. |
I'm actually not sure if I should continue updating this SR as you already closed it. At least for me "this" issue is still unresolved and I can only revert back to 2.3.3 but I can also open a new one if you prefer keeping this ones closed. |
could you please dump the logs from another cli run using the DEBUG var? |
Sure. Already running but it will take a while. Just wanted to give you a quick update. |
It starts like this...
|
Mmm that's all I need. The rest will just be the same thing repeated for each file. Because it's not finding anything, it's going through the resync branch, which is obv pretty intensive (resync TS program, check for source file (return if exists), trigger folder watchers, resync TS program, check for source file (return if exists), check for deleted files, resync TS program, check for source file (return if exists)). I'll try our repo on my old windows laptop and see what happens, as it doesn't repro on mac. Do you have In the interim, I did add another flag to toggle this feature, as a just-in-case. |
My configuration: eslint_typescript_project.js: module.exports = {
parserOptions: {
project: [
'./tsconfig.json',
'./tsconfig.selenium.json'
]
}
}; tsconfig.json: {
"extends": "./configs/tsconfig_base",
"compilerOptions": {
"paths": {
"Source_Data/*": ["./src/data/*"],
"Source_Framework/*": ["./src/framework/*"],
"Source_Modules/*": ["./src/modules/*"],
"Source_ODS/*": ["./src/ods/*"],
"Source_Vendor/*": ["./vendor/*"],
"CoreImg/*": ["./img/*"]
}
},
"include": [
"src",
"test/unittest"
]
} tsconfig.selenium.json: {
"extends": "./configs/tsconfig_base",
"compilerOptions": {
"noEmit": false,
"target": "es2018",
"module": "commonjs"
},
"include": [
"test/selenium/pageobjects",
"test/selenium/tests",
"test/selenium/util"
]
} tsconfig_base.json: {
"compilerOptions": {
"extendedDiagnostics": false,
"noEmit": true,
"downlevelIteration": true,
"allowJs": true,
"checkJs": false,
"sourceMap": true,
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"noImplicitThis": false,
"noUnusedLocals": true,
"noUnusedParameters": false,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"esModuleInterop": true,
"declaration": false,
"importHelpers": true,
"moduleResolution": "node",
"target": "es2015",
"module": "es2015",
"jsx": "react",
"baseUrl": "../",
"outDir": "../temp",
"typeRoots": [
"../node_modules/@types"
],
"lib": [
"es2017",
"dom"
]
},
"compileOnSave": false,
"exclude": [
"node_modules"
]
} |
This is the output when running with |
Hmm, that output is still wrong, though. Your tsconfig isn't missing anything like in #1110, so it's not hitting that case. It must be something different about TS's paths on windows. As an FYI - during a CLI run, the debug output should look like this, in particular it should just be:
|
Uh oh!
There was an error while loading. Please reload this page.
Simply upgrading
eslint-plugin
andparser
from 2.3.3 to 2.4.0 causes eslint to hang at the end of the processing.I've enabled basic debugging
DEBUG=eslint:cli-engine
and the last message iseslint:cli-engine Linting complete in: 110453ms +219ms
and then the eslint command does not seem to return (within several minutes) and I can only kill the process.I have tried this without any change to the sources to be parsed or the configuration and simply upgrading to 2.4.0 makes eslint hang and after moving back to 2.3.3 it does no longer hang.
(I'm aware that I should upload a reproducible test case but given the nature of this problem this seems not possible right now)
Versions
@typescript-eslint/eslint-plugin
2.4.0
@typescript-eslint/parser
2.4.0
TypeScript
3.6.4
ESLint
6.5.1
node
12.12.0
npm
6.12.0
The text was updated successfully, but these errors were encountered: