search

TypeStrong / fork-ts-checker-webpack-plugin

Webpack plugin that runs typescript type checker on a separate process.
MIT License
1.96k stars 240 forks source link

RpcIpcMessagePortClosedError: Process 9160 exited with code "1" #674

Closed vocko closed 2 years ago

vocko commented 2 years ago

Current behavior

I'm getting this error after upgrade to the latest version (6.4.0):

No issues found.
{absolutePathRemoved}\node_modules\typescript\lib\typescript.js:2559
            throw e;
            ^

Error: Debug Failure.
    at {absolutePathRemoved}\node_modules\typescript\lib\typescript.js:19596:89
    at String.replace (<anonymous>)
    at formatStringFromArgs ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:19596:21)
    at Object.createCompilerDiagnostic ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:19701:20)
    at tryReadFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:39904:23)
    at Object.getParsedCommandLineOfConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:39852:30)
    at parseConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120744:43)
    at reloadConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120735:13)
    at updateProgram ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120710:21)
    at updateProgramWithWatchStatus ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120700:13)
{absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19
        closedError = new RpcIpcMessagePortClosedError_1.RpcIpcMessagePortClosedError(code
                      ^

RpcIpcMessagePortClosedError: Process 9160 exited with code "1" [null]
    at {absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19:23
    at Generator.next (<anonymous>)
    at {absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:8:71
    at new Promise (<anonymous>)
    at __awaiter ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:4:12)
    at ChildProcess.handleExit ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:18:42)
    at ChildProcess.emit (node:events:394:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) {
  code: 1,
  signal: null
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Build finishes fine, seems that even the checking as per the "No issues found" line, but then I get this error and the dev server process crashes. Any ideas what can be wrong?

Expected behavior

The previous version 6.3.4 was running fine with no issues (on the same codebase). I have even verified by reverting the yarn upgrade changes in git and running the same command. Works just fine, it must be some change between the 6.3.4 and 6.4.0.

Steps to reproduce the issue

Just running yarn start what runs webpack serve --config webpack.config.development.js

Issue reproduction repository

Environment

devDependencies (all I thought they might be possibly related)
"@typescript-eslint/parser": "^5.4.0", "eslint": "^8.2.0", "eslint-import-resolver-webpack": "^0.13.2", "eslint-plugin-flowtype": "^8.0.3", "eslint-plugin-import": "^2.25.3", "eslint-plugin-jsx-a11y": "^6.5.1", "eslint-plugin-react": "^7.27.0", "fork-ts-checker-webpack-plugin": "^6.4.0", "ts-loader": "^9.2.6", "typescript": "^4.5.2", "webpack": "^5.64.1", "webpack-cli": "^4.9.1", "webpack-dev-server": "^4.5.0"

piotr-oles commented 2 years ago

Hi! Thanks for reporting this issue. Could you create a reproduction repository?

vocko commented 2 years ago

Hi Piotr, thank you for a quick reaction. I will try to put some sample together. The project where it is happening is a little too big, but let's see if I can reproduce it on some extract.

vocko commented 2 years ago

I have tried to reproduce on react-start-app sample, but not successful at least not yet. Even when using the same webpack.config.js, package.json and tsconfig.json. I was also trying to switch between babel-loader and ts-loader but without any effect. I have tried to increase the memory limit and get more logging, but did not give me much light.

I have also tried to set typescript mode parameter to write-references but got the same result.

I don't understand much how all this works under the hood so any help will be appreciated, however, I understand that without reproducible example it might be hard to figure this out.

new ForkTsCheckerWebpackPlugin({
            typescript: {
                memoryLimit: 4096,
                mode: 'write-references'
            },
            logger: {
                infrastructure: 'console',
                issues: 'console',
                devServer: true
            }
        })

Here is my tsconfig.json, if anyone would spot something obviously wrong, but I don't think that's the case.

{
  "compilerOptions": {
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "baseUrl": "./src",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "outDir": "./dist/",
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react",
    "lib": [
      "es2017",
      "ES2015.Promise",
      "dom"
    ],
    "removeComments": true,
    "resolveJsonModule": true,
    "skipLibCheck": false,
    "strict": true,
    "target": "es2017"
  },
  "include": [
    "src/*"
  ]
}

webpack.config.js looks like this

'use strict';

const path = require('path');
const HtmlWebPackPlugin = require('html-webpack-plugin');
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const PUBLIC_PATH = path.resolve(__dirname, 'build');

module.exports = {

    entry: {
        app: './src/index.tsx',
    },
    output: {
        path: PUBLIC_PATH,
        filename: '[name].[contenthash].js',
    },

    resolve: {
        extensions: ['.ts', '.tsx', '.js', '.jsx', '.css', '.scss'],
        fallback: { "stream": false }
    },

    target: 'web',

    mode: 'development',

    devtool: 'eval-source-map',

    devServer: {
        devMiddleware: {
            publicPath: '/',
            index: './index.html'
        },
        static: {
            directory: path.resolve(__dirname, './')
        },
        historyApiFallback: true,
        port: 3000,
        hot: true,
        allowedHosts: [
            'localhost'
        ]
    },

    module: {
        rules: [
            {
                test: /\.(ts|js)x?$/,
                exclude: /node_modules/,
                use: [
                    {
                        loader: 'babel-loader'
                    }
                ]
            },
            {
                test: /\.(s[ac]ss|css)$/,
                use: [
                    {
                        loader: 'style-loader',
                    },
                    {
                        loader: 'css-loader',
                        options: {
                            modules: {
                                localIdentName: '[name]_[local]_[hash:base64:6]',
                                exportLocalsConvention: 'camelCase',
                            },
                            importLoaders: 2,
                            sourceMap: true
                        }
                    },
                    {
                        loader: 'sass-loader',
                        options: {
                            implementation: require('sass'),
                            sourceMap: true
                        },
                    }
                ]
            },
            {
                // Generates a react component wrapping an SVG
                test: /\.svg$/,
                use: [
                    {
                        loader: 'babel-loader'
                    },
                    {
                        loader: '@svgr/webpack',
                        options: {
                            babel: false,
                            dimensions: false,
                            typescript: true,
                            ext: 'tsx',
                            svgoConfig: {
                                plugins: [{
                                    prefixIds: {
                                        prefixIds: false,
                                        prefixClassNames: false
                                    }
                                }]
                            },
                            template: (
                                { template },
                                opts,
                                { imports, componentName, props, jsx, exports }
                            ) => {
                                const typescriptTemplate = template.smart({
                                    plugins: ['typescript'],
                                });

                                // Custom template to allow apply custom colours to an svg from an object
                                // "id" and "data-theme" properties must be set in order to apply the theme
                                // Theme object structure is { primaryColor: '#color', secondaryColor: '#color'}
                                return typescriptTemplate.ast`
                                  ${imports}
                                  const ${componentName}: React.FC<React.SVGProps<SVGSVGElement>> = (props) => ${jsx}
                                  ${exports}
                                `
                            }
                        }
                    },
                ]
            }
        ],
    },
     plugins: [
        new ForkTsCheckerWebpackPlugin(),
        new HtmlWebPackPlugin({
            template: imports.path.resolve(__dirname, 'src/index.ejs'),
            filename: './index.html'
        })
     ]
};

I have also seen this issue which seems similar to mine, but might not be related: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/630

piotr-oles commented 2 years ago

It seems like there is some issue in readFile call in typescript. It's related to this function: image (it may be slightly different on your project - I don't know your exact typescript version)

So you can search for this function in node_modules/typescript/lib/typescript.js file and add a few console.logs, for example, console.log(fileName, e); in the catch block.

vocko commented 2 years ago

It occurs with the latest 4.5.2, but I think I had the same issue with some older version too. I will try to log the function you've said tomorrow and will let you know if I get any usable information out of it.

Thank you for looking into it!

vocko commented 2 years ago

So I have added this logging line:

function tryReadFile(fileName, readFile) {
    var text;
    try {
        text = readFile(fileName);
    }
    catch (e) {
    console.debug(e, fileName, readFile);
        return ts.createCompilerDiagnostic(ts.Diagnostics.Cannot_read_file_0_Colon_1, fileName, e.message);
    }
    console.debug(fileName, text);
    return text === undefined ? ts.createCompilerDiagnostic(ts.Diagnostics.Cannot_read_file_0, fileName) : text;
}

on got this:

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at new NodeError (node:internal/errors:371:5)
    at validateString (node:internal/validators:119:11)
    at Object.normalize (node:path:305:5)
    at normalizePath ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\file-system\RealFileSystem.js:21:39)
    at getRealPath ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\file-system\RealFileSystem.js:67:32)
    at Object.realPath ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\file-system\RealFileSystem.js:153:20)
    at Object.readFile ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\file-system\PassiveFileSystem.js:53:44)
    at Object.readFile ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\reporter\ControlledTypeScriptSystem.js:129:44)
    at Object.readFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:116517:68)
    at {absolutePathRemoved}\node_modules\typescript\lib\typescript.js:39852:92 {
  code: 'ERR_INVALID_ARG_TYPE'
}
undefined
[Function (anonymous)]

And here is the stack trace for the error:

Trace
    at tryReadFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:39907:12)
    at Object.getParsedCommandLineOfConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:39853:24)
    at parseConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120750:43)
    at reloadConfigFile ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120741:13)
    at updateProgram ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120716:21)
    at updateProgramWithWatchStatus ({absolutePathRemoved}\node_modules\typescript\lib\typescript.js:120706:13)
    at Immediate._onImmediate ({absolutePathRemoved}\node_modules\fork-ts-checker-webpack-plugin\lib\typescript-reporter\reporter\ControlledTypeScriptSystem.js:178:17)
    at processImmediate (node:internal/timers:464:21)

Does it give any idea?

As I have said above, it seems it does all the compilation and checking fine and fails after all that is done.

Also, I did try to add the debugging to my last working version and it doesn't seem to make the call at all. When I upgrade the libraries, it seems to do the check twice and fails after the second round. Not sure whether that's an issue with my configuration anywhere, but I have only reverted package.json and yarn.lock, ran yarn install and yarn start and it all went through fine.

These are the libs that work:

"@babel/core": "^7.15.0",
"@babel/preset-env": "^7.15.0",
"@babel/preset-react": "^7.14.5",
"@babel/preset-typescript": "^7.15.0",
"babel-loader": "^8.1.0",
"fork-ts-checker-webpack-plugin": "^6.3.4",
"typescript": "^4.4.4",
"webpack": "^5.58.2",
"webpack-cli": "^4.9.0",
"webpack-dev-server": "^4.3.1"
piotr-oles commented 2 years ago

Could you try to add these lines of code to the node_modules/fork-ts-checker-webpack-plugin/lib/typescript-reporter/reporter/ControlledTypeScriptSystem.js file and check if it solves the issue?

image

vocko commented 2 years ago

Hi Piotr,

this is really annoying now, but I had to revert the libraries to the last working version yesterday as I needed to do some other stuff and once upgraded back to the latest, the issue has disappeared and I can't reproduce it anymore. Possibly any race condition?

I have tried both yarn upgrade and yarn upgrade --latest but not successful, the checker seems to behave correctly suddenly. I think we can close this issue for now, I will reopen it later if I manage to reproduce the problem again. Also will try apply your fix in that case.

Sorry for taking your time, really appreciated for looking into this.

piotr-oles commented 2 years ago

No problem, I'm glad that the problem is solved :)

ghiscoding commented 2 years ago

I have pretty much the same problem, it keeps crashing on my local and I tried to revert to previous TypeScript version (instead of latest) but that didn't help. It happens quite often, not sure if it's specific to a computer or not yet, but I get this error (nearly the same error as described)

closedError = new RpcIpcMessagePortClosedError_1.RpcIpcMessagePortClosedError(code
                      ^
RpcIpcMessagePortClosedError: Process 9108 exited with code "1" [null]

I'm on Windows and I need to go and kill all left open NodeJS thread every time it crashes. I also recently switch to esbuild-loader instead of ts-loader but I'm not sure if that could be the cause yet either.

My project Open Source and is kinda large since it's a monorepo but if it helps, it's available here: Slickgrid-Universal and you can look at my webpack.config.js

vocko commented 2 years ago

@ghiscoding Could you try to apply the fix what Piotr posted above? I wanted to test that but the issue somehow miraculously vanished from my solution and I suddenly can't reproduce it anymore.

ghiscoding commented 2 years ago

@vocko @piotr-oles That patch seems to help, it didn't crash since I updated the code, so it would probably be a good idea to create a PR with this fix.

PenguinDetective commented 2 years ago

Having the same issue as @vocko.

Tried to:

Nothing helped.

Still receiving the same issue (copy from my terminal):

Compiling...
<project_dir>/node_modules/typescript/lib/typescript.js:2559
            throw e;
            ^

Error: Debug Failure.
    at <project_dir>/node_modules/typescript/lib/typescript.js:19608:89
    at String.replace (<anonymous>)
    at formatStringFromArgs (<project_dir>/node_modules/typescript/lib/typescript.js:19608:21)
    at Object.createCompilerDiagnostic (<project_dir>/node_modules/typescript/lib/typescript.js:19713:20)
    at tryReadFile (<project_dir>/node_modules/typescript/lib/typescript.js:39916:23)
    at Object.getParsedCommandLineOfConfigFile (<project_dir>/node_modules/typescript/lib/typescript.js:39864:30)
    at parseConfigFile (<project_dir>/node_modules/typescript/lib/typescript.js:120775:43)
    at reloadConfigFile (<project_dir>/node_modules/typescript/lib/typescript.js:120766:13)
    at updateProgram (<project_dir>/node_modules/typescript/lib/typescript.js:120741:21)
    at updateProgramWithWatchStatus (<project_dir>/node_modules/typescript/lib/typescript.js:120731:13)
<project_dir>/node_modules/react-scripts/scripts/start.js:19
  throw err;
  ^

RpcIpcMessagePortClosedError: Process 7770 exited with code "1" [null]
    at <project_dir>/node_modules/fork-ts-checker-webpack-plugin/lib/rpc/rpc-ipc/RpcIpcMessagePort.js:19:23
    at Generator.next (<anonymous>)
    at <project_dir>/node_modules/fork-ts-checker-webpack-plugin/lib/rpc/rpc-ipc/RpcIpcMessagePort.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (<project_dir>/node_modules/fork-ts-checker-webpack-plugin/lib/rpc/rpc-ipc/RpcIpcMessagePort.js:4:12)
    at ChildProcess.handleExit (<project_dir>/node_modules/fork-ts-checker-webpack-plugin/lib/rpc/rpc-ipc/RpcIpcMessagePort.js:18:42)
    at ChildProcess.emit (events.js:375:28)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12) {
  code: 1,
  signal: null
}

Could it be possible that this issue arises while running webpack, typescript, babel, (or something) else in watch mode, an whenever a checksum of a file changes, that this error is thrown?

I've tried with a project, that has a dependency linked with npm link. When i bundle my files, no error is throw. However, when i run my files through tsc to create .d.ts files, then the error is thrown. Even just changing a single thing in any definition file creates the error during watch mode.

I would be happy to see this issue being opened again.

piotr-oles commented 2 years ago

I don't maintain tsc - if error appears when you run tsc, then you should ask for help on TypeScript repository :)

PenguinDetective commented 2 years ago

I don't posses sufficient knowledge to detect/say who is the culprint - tho it ends at the same error message as the original issue states. I've tried and digger a bit more over the weekend, but couldn't get further. Currently, this is a major bottleneck with a project I'm working on :/

piotr-oles commented 2 years ago

Looking at the stack-trace, there may be some issue with your tsconfig.json

PenguinDetective commented 2 years ago

Which line gives you that hint?

My applications tsconfig.json is:

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "typeRoots": [
      "./node_modules/@types"
    ],
    "noImplicitAny": false,
    "strictNullChecks": false,
    "isolatedModules": true
  },
  "include": [
    "src"
  ]
}

And the library that is available with npm link has this tsconfig.json:

{
  "compilerOptions": {
    // Tells TypeScript to explicitly ignore ".js" files
    "allowJs": false,
    // Tell typescript to use the new JSX runtime
    // https://www.typescriptlang.org/docs/handbook/jsx.html#basic-usage
    "jsx": "react-jsx",
    // Enable interoperability helper between ESM and CJS modules
    // React library yields CJS modules which we import with the "import" statement
    "esModuleInterop": true,
    // Specify the file lookup resolution algorithm when importing
    // We must use the Node.js algorithm
    "moduleResolution": "node",    
    // Types should go into this directory.
    // Removing this would place the .d.ts files next to the .js files
    "outDir": "dist/types",
    // Generate d.ts files
    "declaration": true,
    // This compiler run should only output d.ts files
    "emitDeclarationOnly": true,
    // Create sourcemaps for d.ts files.
    // go to ".js" file when using IDE functions like
    // "Go to Definition" in VSCode
    // "declarationMap": true,
    // Skip type checking all ".d.ts" files.
    "skipLibCheck": true,
    // Ensure that Babel can safely transpile files in the TypeScript project
    "isolatedModules": true
  },
  // Include the following directories
  "include": ["src"],
  // Optional, exclude some patterns from typescript
  "exclude": [
    "dist",
    "node_modules",
    "lib",
    "**/__tests__",
    "**/__mocks__",
    "**/__snapshots__",
    "**/*.test.*",
    "**/*.spec.*",
    "**/*.mock.*"
  ]
}
piotr-oles commented 2 years ago

I have no idea, but you can try commenting-out different options

PenguinDetective commented 2 years ago

I have no idea, but you can try commenting-out different options

Well, if you have no idea, how did you then conclude to:

Looking at the stack-trace, there may be some issue with your tsconfig.json

Not trying to offend, just curious.

piotr-oles commented 2 years ago

ah, I misread the stack trace... I read it from bottom to top, but it is from top to bottom 🤦🏻

PenguinDetective commented 2 years ago

ah, I misread the stack trace... I read it from bottom to top, but it is from top to bottom 🤦🏻

Ahh i see - no worries. But any insights then on what triggers the error? This currently keeps me from development.

Keavon commented 2 years ago

I'm having this issue also after I upgraded my project from Vue-CLI-4 (using WebPack 4) to Vue-CLI-5 (using WebPack 5). Specifically it's @vue/cli-plugin-typescript that depends on fork-ts-checker-webpack-plugin. I have fully deleted my package-lock.json and node_modules folder, redid npm install, and then npm run serve causes this. Sorry for the Vue-specific stuff in the nature of my problem description, since I understand this project doesn't directly pertain to Vue. Here is my full log just for completeness.

C:\Users\Keavon\Projects\Graphite\frontend>npm run serve

> serve
> vue-cli-service serve || echo 'Graphite project failed to build. Did you remember to `npm install` the dependencies?'

 INFO  Starting development server...
[6%] setup (before compile WasmPackPlugin)
🧐  Checking for wasm-pack...

✅  wasm-pack is installed at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\.bin\wasm-pack.CMD. 

ℹ️  Compiling your crate in development mode...

[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
    Finished dev [optimized + debuginfo] target(s) in 0.09s
[WARN]: :-) origin crate has no README
[INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory
[INFO]: Installing wasm-bindgen...
[INFO]: Optional field missing from Cargo.toml: 'description'. This is not necessary, but recommended
[INFO]: :-) Done in 0.72s
[INFO]: :-) Your wasm pkg is ready to publish at C:\Users\Keavon\Projects\Graphite\frontend\wasm\pkg.
✅  Your crate has been correctly compiled

 DONE  Compiled successfully in 11709ms                                                                                                                                                                   5:21:28 PM

  App running at:
  - Local:   http://localhost:8080/
  - Network: http://192.168.1.11:8080/

  Note that the development build is not optimized.
  To create a production build, run npm run build.

 WAIT  Compiling...                                                                                                                                                                                       5:21:28 PM

Compiling...
No issues found.
[51%] building (25/14 modules)
C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:2559
            throw e;
            ^

Error: Debug Failure.
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19608:89
    at String.replace (<anonymous>)
    at formatStringFromArgs (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19608:21)
    at Object.createCompilerDiagnostic (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19713:20)        
    at tryReadFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:39916:23)
    at Object.getParsedCommandLineOfConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:39864:30)
    at parseConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:120775:43)
    at reloadConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:120766:13)
    at updateProgram (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:120741:21)
    at updateProgramWithWatchStatus (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:120731:13)
C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19
        closedError = new RpcIpcMessagePortClosedError_1.RpcIpcMessagePortClosedError(code
                      ^

RpcIpcMessagePortClosedError: Process 2796 exited with code "1" [null]
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19:23
    at Generator.next (<anonymous>)
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:4:12)
    at ChildProcess.handleExit (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:18:42)
    at ChildProcess.emit (node:events:390:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) {
  code: 1,
  signal: null
}

Here is my project with the branch for this failing Vue CLI 5 upgrade.

I did try the undefined check in ControlledTypeScriptSystem.js without success. Happy to help trying to debug it in other ways that might be suggested. Thank you!

kegi commented 2 years ago

Also having this issue with React CRA. My issue is very similar to @PenguinDetective . I have a linked dependency and when declaration files changed on that library (with tsc-watch) fork-ts-checker-webpack-plugin crash.

PenguinDetective commented 2 years ago

@piotr-oles Would you mind having a look at this issue again? It's been a month and it's still a bottleneck.

brunogarciavaz commented 2 years ago

This happens every time I pull in commits from the repository, and stops happening after I reinstall node_modules (remove folder and yarn)

Might be a clue? React CRA centos

piotr-oles commented 2 years ago

@Keavon Thanks for the reproduction repository. I was able to reproduce this issue in the Graphite repo. It seems that it's caused by a change of the frontend/wasm/package.json file during the build, which triggers some code-path that is valid in WatchCompilerHostOfConfigFile but not in WatchCompilerHostOfFilesAndCompilerOptions that this plugin uses (because of configOverwrite option). I'm thinking about how to solve this, but probably the easiest fix would be to ignore package.json in the watcher.

KurtGokhan commented 2 years ago

Happened to me after updating my dependencies. Gone away after deleting node_modules and lock file and installing dependencies again.

piotr-oles commented 2 years ago

:tada: This issue has been resolved in version 7.2.3 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Keavon commented 2 years ago

Thank you @piotr-oles for setting up the Graphite repo and debugging the issue to make the fix! I have overridden the version to force an upgrade to 7.2.3 but now I'm seeing this other error. Should I file a separate issue for it?

C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:2552
            throw e;
            ^

Error: Debug Failure.
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:89
    at String.replace (<anonymous>)
    at formatStringFromArgs (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:21)
    at Object.createCompilerDiagnostic (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19789:20)        
    at tryReadFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:40088:23)
    at Object.getParsedCommandLineOfConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:40036:30)
    at parseConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121814:43)
    at reloadConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121805:13)
    at updateProgram (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121780:21)
    at updateProgramWithWatchStatus (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121770:13)
RpcExitError: Process 8332 exited with code "1" [null]
Issues checking service aborted - probably out of memory. Check the `memoryLimit` option in the ForkTsCheckerWebpackPlugin configuration.

I updated the branch so if you pull the latest commit and then cd frontend && npm install, this should be reproducible. Sorry to hassle you but thank you!

vocko commented 2 years ago

@Keavon Did you try increase the memory limit in the config?

Details are here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#typescript-options

Keavon commented 2 years ago

@vocko thanks for the suggestion, but no dice.

Adding a fork-ts-checker.config.js file with:

module.exports = {
    typescript: {
        memoryLimit: 9999999999,
    },
};

didn't fix it. This also wasn't an issue before.

eowino commented 2 years ago

🎉 This issue has been resolved in version 7.2.3 🎉

The release is available on:

Your semantic-release bot 📦🚀

@piotr-oles I am using create-react-app, and I just tried this patch out locally by modifying it in node_modules and it seems to work. Thank you!

Given they are currently on v6.5.0, would it be possible to get a patch for v6.5.0 as well to ease the transition until create-react-app migrates to the latest version of fork-ts-checker-webpack-plugin?

Keavon commented 2 years ago

@piotr-oles I am using create-react-app, and I just tried this patch out locally by modifying it node_modules and it seems to work. Thank you!

Given they are currently on v6.5.0, would it be possible to get a patch for v6.5.0 as well to ease the transition until create-react-app migrates to the latest version of fork-ts-checker-webpack-plugin?

Likewise for Vue CLI, they are using ^6.4.0 in @vue/cli-plugin-typescript. There's a chance that the problem I posted above is a bug caused by an incompatibility between 6.x and 7.x. I did post a feature request for them to upgrade to 7.x. But a backport would be a helpful step if it's not too difficult! Thank you!

piotr-oles commented 2 years ago

I created a PR :) I didn't test backporting feature of semantic release before, so let's hope this will work :D

Keavon commented 2 years ago

Thank you for the backport, @piotr-oles! I really appreciate your efforts. Hopefully this may have helped solve the problem for @eowino.

Sadly, for Graphite, this still didn't fix it though, I'm sorry to say :(

I deleted the overrides section of package.json as well as node_modules/ and package-lock.json and ran npm update. I confirmed with npm list fork-ts-checker-webpack-plugin that it's now using the 6.5.1 version with the backported fix:

graphite-web-frontend@ C:\Users\Keavon\Projects\Graphite\frontend
└─┬ @vue/cli-plugin-typescript@5.0.4
  └── fork-ts-checker-webpack-plugin@6.5.1

But this is the output when trying to build (npm run serve) the project:

 INFO  Starting development server...
[6%] setup (before compile WasmPackPlugin)
🧐  Checking for wasm-pack...

✅  wasm-pack is installed at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\.bin\wasm-pack.CMD. 

ℹ️  Compiling your crate in development mode...

[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
   Compiling graphite-graphene v0.0.0 (C:\Users\Keavon\Projects\Graphite\graphene)
   Compiling graphite-editor v0.0.0 (C:\Users\Keavon\Projects\Graphite\editor)
   Compiling graphite-wasm v0.0.0 (C:\Users\Keavon\Projects\Graphite\frontend\wasm)
    Finished dev [optimized + debuginfo] target(s) in 9.16s
[WARN]: :-) origin crate has no README
[INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory
[INFO]: Installing wasm-bindgen...
[INFO]: Optional field missing from Cargo.toml: 'description'. This is not necessary, but recommended
[INFO]: :-) Done in 9.76s
[INFO]: :-) Your wasm pkg is ready to publish at C:\Users\Keavon\Projects\Graphite\frontend\wasm\pkg.
[WARN]: :-) There's a newer version of wasm-pack available, the new version is: 0.10.2, you are using: 0.10.1. To update, navigate to: https://rustwasm.github.io/wasm-pack/installer/
✅  Your crate has been correctly compiled

 DONE  Compiled successfully in 25996ms                                                                                                                                                                                                                                              10:54:33 PM

  App running at:
  - Local:   http://localhost:8080/
  - Network: http://192.168.1.10:8080/

  Note that the development build is not optimized.
  To create a production build, run npm run build.

No issues found.

 WAIT  Compiling...                                                                                                                                                                                                                                                                  10:54:33 PM

Compiling...
[51%] building (27/15 modules)
C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:2552
            throw e;
            ^

Error: Debug Failure.
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:89
    at String.replace (<anonymous>)
    at formatStringFromArgs (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:21)
    at Object.createCompilerDiagnostic (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:19789:20)        
    at tryReadFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:40088:23)
    at Object.getParsedCommandLineOfConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:40036:30)
    at parseConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121814:43)
    at reloadConfigFile (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121805:13)
    at updateProgram (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121780:21)
    at updateProgramWithWatchStatus (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\typescript\lib\typescript.js:121770:13)
C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19
        closedError = new RpcIpcMessagePortClosedError_1.RpcIpcMessagePortClosedError(code
                      ^

RpcIpcMessagePortClosedError: Process 38140 exited with code "1" [null]
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19:23
    at Generator.next (<anonymous>)
    at C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:4:12)
    at ChildProcess.handleExit (C:\Users\Keavon\Projects\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:18:42)
    at ChildProcess.emit (node:events:390:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) {
  code: 1,
  signal: null
}

I have updated the project's upgrade-vue-cli branch with the changes to package.json and package-lock.json to incorporate 6.5.1.

I'd be happy to help with debugging in any way possible, although my familiarity with the code or its usage in the dependency tree is quite limited at the moment. Thank you for your assistance in this matter and I hope I can help you solve it. ❤️

piotr-oles commented 2 years ago

@Keavon I wasn't able to reproduce this bug on the updated branch. Could you provide me with the exact steps? I was trying modifying .ts, .vue, and .rs files, but everything worked for me. Also, could you tell me which OS and Node version you use?

Keavon commented 2 years ago

@piotr-oles that's certainly interesting to hear. It builds and lets you open the web interface at localhost:8080? I just verified it's still a problem by re-cloning the project from scratch to a new location. My steps:

git clone https://github.com/GraphiteEditor/Graphite.git
cd Graphite
git switch upgrade-vue-cli
cd frontend
npm install
npm start
And my console history (click to show): 
C:\Users\Keavon\Desktop>git clone https://github.com/GraphiteEditor/Graphite.git
Cloning into 'Graphite'...
remote: Enumerating objects: 9536, done.
remote: Counting objects: 100% (1743/1743), done.
remote: Compressing objects: 100% (1040/1040), done.
remote: Total 9536 (delta 1034), reused 1231 (delta 682), pack-reused 7793
Receiving objects: 100% (9536/9536), 11.82 MiB | 18.82 MiB/s, done.
Resolving deltas: 100% (5970/5970), done.

C:\Users\Keavon\Desktop>cd Graphite

C:\Users\Keavon\Desktop\Graphite>git switch upgrade-vue-cli
Switched to a new branch 'upgrade-vue-cli'
Branch 'upgrade-vue-cli' set up to track remote branch 'upgrade-vue-cli' from 'origin' by rebasing.

C:\Users\Keavon\Desktop\Graphite>cd frontend

C:\Users\Keavon\Desktop\Graphite\frontend>npm install

added 931 packages, and audited 932 packages in 8s

121 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

C:\Users\Keavon\Desktop\Graphite\frontend>npm start

> start
> vue-cli-service serve

 INFO  Starting development server...
[6%] setup (before compile WasmPackPlugin)
🧐  Checking for wasm-pack...

✅  wasm-pack is installed at C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\.bin\wasm-pack.CMD.

ℹ️  Compiling your crate in development mode...

[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
   Compiling proc-macro2 v1.0.36
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.87
   Compiling log v0.4.14
   Compiling serde_derive v1.0.136
   Compiling wasm-bindgen-shared v0.2.79
   Compiling serde v1.0.136
   Compiling cfg-if v1.0.0
   Compiling bumpalo v3.9.1
   Compiling lazy_static v1.4.0
   Compiling unicode-general-category v0.4.0
   Compiling wasm-bindgen v0.2.79
   Compiling scopeguard v1.1.0
   Compiling unicode-script v0.5.4
   Compiling ttf-parser v0.15.0
   Compiling bitflags v1.3.2
   Compiling smallvec v1.8.0
   Compiling unicode-bidi-mirroring v0.1.0
   Compiling unicode-ccc v0.1.2
   Compiling bytemuck v1.8.0
   Compiling arrayvec v0.7.2
   Compiling serde_json v1.0.79
   Compiling ryu v1.0.9
   Compiling ppv-lite86 v0.2.16
   Compiling itoa v1.0.1
   Compiling rand_core v0.6.3
   Compiling fnv v1.0.7
   Compiling lock_api v0.4.6
   Compiling rand_chacha v0.3.1
   Compiling spin v0.9.2
   Compiling quote v1.0.15
   Compiling rustybuzz v0.5.0
   Compiling wasm-bindgen-backend v0.2.79
   Compiling wasm-bindgen-macro-support v0.2.79
   Compiling wasm-bindgen-macro v0.2.79
   Compiling thiserror-impl v1.0.30
   Compiling remain v0.2.2
   Compiling derivative v2.2.0
   Compiling graphite-proc-macros v0.0.0 (C:\Users\Keavon\Desktop\Graphite\proc-macros)
   Compiling js-sys v0.3.56
   Compiling thiserror v1.0.30
   Compiling kurbo v0.8.3 (https://github.com/GraphiteEditor/kurbo.git#552bbe2d)
   Compiling glam v0.17.3
   Compiling serde-wasm-bindgen v0.4.2
   Compiling graphite-graphene v0.0.0 (C:\Users\Keavon\Desktop\Graphite\graphene)
   Compiling graphite-editor v0.0.0 (C:\Users\Keavon\Desktop\Graphite\editor)
   Compiling graphite-wasm v0.0.0 (C:\Users\Keavon\Desktop\Graphite\frontend\wasm)
    Finished dev [optimized + debuginfo] target(s) in 47.05s
[WARN]: :-) origin crate has no README
[INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory
[INFO]: Installing wasm-bindgen...
[INFO]: Optional field missing from Cargo.toml: 'description'. This is not necessary, but recommended
[INFO]: :-) Done in 47.66s
[INFO]: :-) Your wasm pkg is ready to publish at C:\Users\Keavon\Desktop\Graphite\frontend\wasm\pkg.
[WARN]: :-) There's a newer version of wasm-pack available, the new version is: 0.10.2, you are using: 0.10.1. To update, navigate to: https://rustwasm.github.io/wasm-pack/installer/
✅  Your crate has been correctly compiled

 DONE  Compiled successfully in 65197ms                                                                       8:20:54 AM

  App running at:
  - Local:   http://localhost:8081/
  - Network: http://192.168.1.10:8081/

  Note that the development build is not optimized.
  To create a production build, run npm run build.

No issues found.

 WAIT  Compiling...                                                                                           8:20:54 AM

Compiling...
[51%] building (27/13 modules)
C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:2552
            throw e;
            ^

Error: Debug Failure.
    at C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:89
    at String.replace ()
    at formatStringFromArgs (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:19675:21)
    at Object.createCompilerDiagnostic (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:19789:20)
    at tryReadFile (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:40088:23)
    at Object.getParsedCommandLineOfConfigFile (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:40036:30)
    at parseConfigFile (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:121814:43)
    at reloadConfigFile (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:121805:13)
    at updateProgram (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:121780:21)
    at updateProgramWithWatchStatus (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\typescript\lib\typescript.js:121770:13)
C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19
        closedError = new RpcIpcMessagePortClosedError_1.RpcIpcMessagePortClosedError(code
                      ^

RpcIpcMessagePortClosedError: Process 25020 exited with code "1" [null]
    at C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:19:23
    at Generator.next ()
    at C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:8:71
    at new Promise ()
    at __awaiter (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:4:12)
    at ChildProcess.handleExit (C:\Users\Keavon\Desktop\Graphite\frontend\node_modules\fork-ts-checker-webpack-plugin\lib\rpc\rpc-ipc\RpcIpcMessagePort.js:18:42)
    at ChildProcess.emit (node:events:390:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) {
  code: 1,
  signal: null
}

I'm using these versions: Windows 10 Pro 20H2 node v16.13.1 npm 8.5.5 rustc 1.60.0 wasm-pack 0.10.1 (check via npx wasm-pack --version — this is installed globally by the node package, and it's pinned one minor version behind from the latest 0.10.2)

I can ask others on the team, using different OSs, to try the branch if that'd be helpful.

piotr-oles commented 2 years ago

I repeated these steps on MacOS and I didn't have this error. I suspect there is some difference in file watcher between Windows and Mac. I don't know how to configure this in vue cli, but could you try to enable infrastructure logging for the plugin? Like here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/test/e2e/fixtures/typescript-basic/webpack.config.js#L30-L33 This should show more details about watcher behaviour.

Keavon commented 2 years ago

Thanks @piotr-oles. I've confirmed with other team members that this doesn't happen on Mac and Linux, but it does on multiple of my Windows machines. It also doesn't happen with WSL on Windows.

I tried adding that like so to my vue.config.js:

module.exports = {
    ...
    configureWebpack: {
        experiments: {
            asyncWebAssembly: true,
        },
        infrastructureLogging: {
            level: "log",
            debug: /ForkTsCheckerWebpackPlugin/,
        },
    },
};

However the output is the same with or without that, there's no actual logging showing up. Do you have a feel for whether this might be a Vue-related issue (in which case, perhaps I can post on some Vue forums asking for help) or do you have any other theories why it might be otherwise not showing the logging? Is "log" and the regex /ForkTsCheckerWebpackPlugin/ correct? I did confirm that infrastructureLogging is a validated field in that place because I intentionally added a typo to infrastructureLogging and it complained about an invalid field. Happy to help continue debugging, I'm sorry that this seems to be related to some things you don't directly use (Windows and possibly Vue) but I'll do what I can to hopefully help out.

(The updated code, with infrastructureLogging, is committed to that branch.)

piotr-oles commented 2 years ago

Thanks for the detailed response. I will create an e2e test with a project that triggers package.json change. It will run in our CI on a Windows machine. I hope I will be able to reproduce the bug this way. Regarding logging, I didn't have time to debug this but my bet is that vue cli is not passing these options correctly to the webpack 🤔 But that's just a guess. These settings works in our e2e tests so I think they are correct. Here is a test fixture where we use it: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/test/e2e/fixtures/typescript-basic/webpack.config.js

piotr-oles commented 2 years ago

:tada: This issue has been resolved in version 7.2.7 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Keavon commented 2 years ago

Thank you @piotr-oles! Would you be so kind as to backport this again to the 6.x series? (This would ensure the latest version of the 6.x series doesn't remain broken on Windows.) Unfortunately Vue-CLI hasn't upgraded to 7.x. I really appreciate your time and effort that went into debugging this through the Windows CI server!

piotr-oles commented 2 years ago

:tada: This issue has been resolved in version 6.5.2 :tada:

The release is available on:

Your semantic-release bot :package::rocket: