RpcIpcMessagePortClosedError: Process 9160 exited with code "1" #674
Comments
|
Hi! Thanks for reporting this issue. Could you create a reproduction repository? |
|
Hi Piotr, |
|
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: #630 |
|
It seems like there is some issue in So you can search for this function in |
|
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! |
|
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: And here is the stack trace for the error: 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 These are the libs that work: |
|
Could you try to add these lines of code to the
|
|
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 Sorry for taking your time, really appreciated for looking into this. |
|
No problem, I'm glad that the problem is solved :) |
|
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 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 |
|
@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. |
|
@vocko @piotr-oles |
|
Having the same issue as @vocko. Tried to:
Nothing helped. Still receiving the same issue (copy from my terminal): 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 I would be happy to see this issue being opened again. |
|
I don't maintain |
|
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 :/ |
|
Looking at the stack-trace, there may be some issue with your tsconfig.json |
|
Which line gives you that hint? My applications {
"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 {
"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.*"
]
} |
|
I have no idea, but you can try commenting-out different options |
Well, if you have no idea, how did you then conclude to:
Not trying to offend, just curious. |
|
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. |
|
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 Here is my project with the branch for this failing Vue CLI 5 upgrade. I did try the |
|
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) |
|
@piotr-oles Would you mind having a look at this issue again? It's been a month and it's still a bottleneck. |
|
This happens every time I pull in commits from the repository, and stops happening after I reinstall node_modules (remove folder and Might be a clue? |
|
🎉 This issue has been resolved in version 7.2.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
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? I updated the branch so if you pull the latest commit and then |
|
@Keavon Did you try increase the memory limit in the config? Details are here: |
|
@vocko thanks for the suggestion, but no dice. Adding a module.exports = {
typescript: {
memoryLimit: 9999999999,
},
};didn't fix it. This also wasn't an issue before. |
@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? |
Likewise for Vue CLI, they are using |
|
I created a PR :) I didn't test backporting feature of semantic release before, so let's hope this will work :D |
The error in #674 is caused by a change of the 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 the configOverwrite option). This commit ignores the package.json file in watcher as a work-around.
|
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 But this is the output when trying to build ( I have updated the project's 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. ❤️ |
|
@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 |
|
@piotr-oles that's certainly interesting to hear. It builds and lets you open the web interface at git clone https://github.com/GraphiteEditor/Graphite.git
cd Graphite
git switch upgrade-vue-cli
cd frontend
npm install
npm startAnd 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.
Note that the development build is not optimized. No issues found. WAIT Compiling... 8:20:54 AM Compiling... Error: Debug Failure. RpcIpcMessagePortClosedError: Process 25020 exited with code "1" [null] I'm using these versions: I can ask others on the team, using different OSs, to try the branch if that'd be helpful. |
|
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. |
|
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 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 (The updated code, with |
|
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. |
|
🎉 This issue has been resolved in version 7.2.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
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! |
|
🎉 This issue has been resolved in version 6.5.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Current behavior
I'm getting this error after upgrade to the latest version (6.4.0):
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.jsIssue 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"
The text was updated successfully, but these errors were encountered: