Skip to content
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

Builds fail when using thread-loader and webpack >= 4.13.0 #1242

Closed
caseyjhol opened this issue Jan 21, 2021 · 3 comments
Closed

Builds fail when using thread-loader and webpack >= 4.13.0 #1242

caseyjhol opened this issue Jan 21, 2021 · 3 comments

Comments

@caseyjhol
Copy link

Similar to #1206, but since that issue has been resolved, I figured I'd open a new issue to keep the discussion separate.

Expected Behaviour

Using thread-loader before ts-loader, compilation of a project should succeed.

Actual Behaviour

Compilation fails with this error:

yarn run v1.22.5
warning package.json: No license field
$ webpack
[webpack-cli] Compilation finished
Hash: 544620ab4b9aa5be4c32
Version: webpack 4.44.2
Time: 564ms
Built at: 01/20/2021 5:32:04 PM
    Asset      Size  Chunks  Chunk Names
bundle.js  8.12 KiB       0  main
Entrypoint main = bundle.js
[0] ./src/app.ts 1.12 KiB {0} [built] [failed] [1 error]

ERROR in ./src/app.ts
Module build failed (from ./node_modules/thread-loader/dist/cjs.js):
Thread Loader (Worker 0)
Cannot read property 'hooks' of undefined
    at PoolWorker.fromErrorObj (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/thread-loader/dist/WorkerPool.js:344:12)
    at /home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/thread-loader/dist/WorkerPool.js:217:29
    at mapSeries (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/neo-async/async.js:3625:14)
    at PoolWorker.onWorkerMessage (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/thread-loader/dist/WorkerPool.js:171:34)
    at Object.initializeInstance (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/ts-loader/dist/instances.js:264:31)
    at successLoader (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/ts-loader/dist/index.js:26:17)
    at Object.loader (/home/cholzer/git/caseyjhol/tsloader-build-issue-with-thread-loader/node_modules/ts-loader/dist/index.js:23:5)
error Command failed with exit code 1.

Steps to Reproduce the Problem

Use a minimal webpack configuration as follows:

module.exports = {
  devtool: "inline-source-map",
  entry: "./src/app.ts",
  output: {
    filename: "bundle.js",
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: ["thread-loader", "ts-loader"],
      },
    ],
  },
};

Running builds with webpack should fail.
Reproducible with the following dependencies:

    "thread-loader": "3.0.1",
    "ts-loader": "8.0.11",
    "typescript": "4.0.5",
    "webpack": "4.44.2"

Location of a Minimal Repository that Demonstrates the Issue.

https://github.com/caseyjhol/tsloader-build-issue-with-thread-loader

@appzuka
Copy link
Member

appzuka commented Jan 22, 2021

@caseyjhol, As noted in the ts-loader readme, you will need to set happyPackMode to true if you are using thread-loader:

https://github.com/TypeStrong/ts-loader#happypackmode

Your rule in webpack will be:

    rules: [
      {
        test: /\.tsx?$/,
        use: [
          {
            loader: 'thread-loader'
          },
          {
            loader: 'ts-loader',
            options: {
              happyPackMode: true
            }
          }
        ]
      },
    ],

With this your repo builds. This config disables all error checking so you will want to configure fork-ts-checker-webpack-plugin to re-enable it.

I question whether thread-loader will bring you more performance or whether its overhead will slow down the build. If you are not using transpileOnly mode with ts-loader then you cannot use thread-loader as it requires that the loaders it parallelizes are very simple with no side-effects.

Using transpileOnly and fork-ts-checker-webpack-plugin you should see a nice speed boost as you are taking the error checking off the main thread. If your project is huge you could consider using project references so you pre-compile modules within your project. Before using thread-loader I would suggest you benchmark the build with and without and check that it gives you some benefit.

@caseyjhol
Copy link
Author

Interesting. In my actual build, I already had both happyPackMode and transpileOnly set to true. I'm getting this error:

Running webpack ...

94% after seal ERROR  Failed to compile with 1 errors                                                                                                                  8:17:57 PM

 error  in ./assets/js/react-app/App.tsx

Syntax Error: Thread Loader (Worker 0)
Cannot read property 'hooks' of undefined


 @ ./assets/js/app.js 11:0-34 12:107-110

I'll see if I can create a reduced test case.

@caseyjhol
Copy link
Author

I'm using Webpack Encore, and it was adding ts-loader for me. I was looping through the loaders and adjusting the settings only if it was ts-loader. The way I was checking was incorrect. I was checking for an exact string match (loader.loader === "ts-loader"), but there was more to the string than that. Using includes fixes it. 🤦

Thanks for your help!

Encore.getWebpackConfig().module.rules.forEach((rule) => {
	if (rule.test.test(".ts")) {
		rule.use.forEach((loader) => {
			if (loader.loader.includes("ts-loader")) {
				loader.options.happyPackMode = true;
				loader.options.transpileOnly = true;
			}
		});
		rule.use.unshift({
			loader: "thread-loader",
			options: {
				workers: require("os").cpus().length - 2,
			},
		});
	}
});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants