build gets stuck at "after chunk asset optimization"

[krskrs]

What is the current behaviour?
Recently I have updated to the latest (stable) 3.5.0 version of Preact CLI and I started facing an issue where build would randomly (i mean not on every build) get stuck at this phase:

then, if I stop the build process and start it again, it would most likely finish without any issues.

So far I haven't been able to find any clues on when this happens, except for the fact that it seems more likely to happen when the ide has been opened for several hours, and less prone to happen on first builds. But let's not count on this, it could also be a suggestion.

Anyways, is there anything I could do just to get more detailed information which might help to pinpoint or debug more thoroughly the issue?

npx preact-cli info

Environment Info:
  System:
    OS: Windows 10 10.0.19045
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
  Binaries:
    Node: 20.11.0 - ~\AppData\Local\nvs\default\node.EXE
    npm: 10.2.4 - ~\AppData\Local\nvs\default\npm.CMD
  Browsers:
    Chrome: 120.0.6099.217
    Edge: Chromium (120.0.2210.133)
  npmPackages:
    preact: ^10.3.1 => 10.6.6
    preact-cli: ^3.5.0 => 3.5.0
    preact-render-to-string: ^5.1.4 => 5.1.19

[krskrs]

I can also add that the before updating, I was using preact-cli 3.3.4 and had never experienced such issue. Then I went from 3.3.4 directly to 3.5.0 and the problem started.

[rschristian]

You can try enabling verbose Webpack stats, I don't believe CLI's --verbose flag sets that.

I can also add that the before updating, I was using preact-cli 3.3.4 and had never experienced such issue. Then I went from 3.3.4 directly to 3.5.0 and the problem started.

You can try to git bisect to find the troublesome commit (& preferably the troublesome change itself), but if you're struggling to reliably reproduce it, that may take a while.

Keep in mind Preact-CLI is unmaintained -- I'd recommend bumping up to v4 and then move onto Vite via create-preact when possible.

[krskrs]

Hi @rschristian and thanks for the quick response!
So, I couldn't use stats, because when the issue occurs, compiler.run() won't return and so I haven't access to the stats object.
Then I looked a bit into the code and managed to hack this directly into webpack-base-config.js (I suppose it could have been done from preact config file, but this was quicker for me, just for debugging)

This allowed to determine where the build is exactly hanging:

			...(tsconfig
				? [
						new ForkTsCheckerWebpackPlugin({
							checkSyntacticErrors: true,
							async: !isProd,
							tsconfig: tsconfig,
							silent: !isWatch,
						}),

and the funny thing is that this dependency stayed exactly the same between cli 3.3.4 (where build never got stuck) and 3.5.0. So it must be some other thing which got updated and started to interfere with it, maybe ts itself, who knows.

I would like to switch to Vite, but this is a production project, quite big, and at this time we haven't the resources for planning such a big switch.

So at present, we can either further dig into the issue, or try Preact-CLI v4, but is it still being developed? Or is the entire project unmaintained?

[rschristian]

So, I couldn't use stats, because when the issue occurs, compiler.run() won't return and so I haven't access to the stats object.

Odd, never seen that before.

the funny thing is that this dependency stayed exactly the same between cli 3.3.4 (where build never got stuck) and 3.5.0.

That dep might not have changed, but #1798 would probably have an effect. Worth checking. Might be worth checking if it's outputting anything too:

new ForkTsCheckerWebpackPlugin({
	checkSyntacticErrors: true,
	async: !isProd,
	tsconfig: tsconfig,
-	silent: !isWatch,
+	silent: false,
}),

Narrowing down the version range would also help, there's 8 versions between 3.3.4 and 3.5.0.

So at present, we can either further dig into the issue, or try Preact-CLI v4, but is it still being developed? Or is the entire project unmaintained?

It's a loose "unmaintained" -- I may pop in to fix some things that I need, and I'll (eventually) have time to review fixes if someone in the community wants to submit some, but I'm not going to be developing it any further.

[krskrs]

I wanted to follow up on this. After investigating quite a bit, I found out that the 4.x version of ForkTsCheckerWebPack plugin, which 3.5 version is depending on, seems to have some race/odd issues with the latest 4.9.x typescript versions. In fact all started after updating preact-cli to 3.5 and, as a consequence of #1798 , having ts updated to the latest version of the 4.9 branch.

In the end I managed to find a good compromise to make everything work (upgrading ForkTsChecker to the 6.x branch and 2 tiny patches on preact-cli regarding the new fts configuration format, and disabling it for the babel-esm plugin which triggers another apply on all plugins).

Now, I know that the 4.x version has newer dependencies but, since it also has some potentially breaking changes (or that's what I assumed after reading some information here here in the repo), in case somebody with big code bases want/need to stick with the 3.x branch for a while longer, I can submit a PR, if you think it might be useful

Thanks again for the support!

[rschristian]

In fact all started after updating preact-cli to 3.5 and, as a consequence of #1798 , having ts updated to the latest version of the 4.9 branch.

That is not what #1798 did, no. It did the opposite of that in fact, it removed TS altogether.

Because we shipped a version of TS w/ CLI, the issue was that, with Node's module resolution, dependencies of CLI (like fork-ts-checker) would (usually) prefer other CLI dependencies, such as TS. This was an issue as it made it quite difficult to use different versions of TS w/ Preact-CLI.

By removing the dependency, users are expected to provide their own version if they need it. This should be pretty clear in the release notes.

In the end I managed to find a good compromise to make everything work (upgrading ForkTsChecker to the 6.x branch and 2 tiny patches on preact-cli regarding the new fts configuration format, and disabling it for the babel-esm plugin which triggers another apply on all plugins).

A better solution might be to downgrade your project's TS version to what was previously in use, rather than patching CLI.

I can submit a PR, if you think it might be useful

If you'd like, though IIRC, newer versions caused other issues. If the test suite passes I'd be happy to merge though.

[krskrs]

In fact all started after updating preact-cli to 3.5 and, as a consequence of #1798 , having ts updated to the latest version of the 4.9 branch.

That is not what #1798 did, no. It did the opposite of that in fact, it removed TS altogether.

Because we shipped a version of TS w/ CLI, the issue was that, with Node's module resolution, dependencies of CLI (like fork-ts-checker) would (usually) prefer other CLI dependencies, such as TS. This was an issue as it made it quite difficult to use different versions of TS w/ Preact-CLI.

By removing the dependency, users are expected to provide their own version if they need it. This should be pretty clear in the release notes.

yes, my bad, I haven't been clear, and indeed the description and the aim of your change is clear. What I meant was something like an indirect consequence of the change: passing from a "real" dependency to a peer dependency, made npm install "touch" the ts in my installation, removing CLI's own ts version and at the same time taking the chance to update my root ts installation, which ended up to v4.9.5, satisfying both your now peer dependency ("typescript": "^4.6.4") and my main dependency in package.json ("typescript": "^4.5.2")

In the end I managed to find a good compromise to make everything work (upgrading ForkTsChecker to the 6.x branch and 2 tiny patches on preact-cli regarding the new fts configuration format, and disabling it for the babel-esm plugin which triggers another apply on all plugins).

A better solution might be to downgrade your project's TS version to what was previously in use, rather than patching CLI.

yes, I totally agree that patching a package is 100% bad practice, even more if patched by hand as I did (but I was just hacking out, I almost debugged all forkTsChecker 😄 in the process). That's one of the reasons I was also proposing the PR, the other being that I believe what happened to me could happen to others.

I can submit a PR, if you think it might be useful

If you'd like, though IIRC, newer versions caused other issues. If the test suite passes I'd be happy to merge though.

[rschristian]

(Sorry, missed this)

I totally agree that patching a package is 100% bad practice

I don't actually think that, I patch like a mad man sometimes to be honest! A-ok to do so in my book.

There's just not a ton of new TS constructs since, so I was assuming it'd be easier to downgrade TS than maintain a patch, but I see nothing wrong with it either way -- just a guess as to what might be easier.

[krskrs]

Hi @rschristian!
Yes, and, putting patching theories aside 😄, I can tell you that I've been working with the 'patched' version and no more hangs so far, and now I believe I can say for good. So I'll see if I manage to make that pull request for the 3.x branch. I haven't put aside the idea of doing it. And we're talking of tiny and "secure" changes, I'd say.

[krskrs]

ook, here we go: https://github.com/krskrs/preact-cli/tree/3.x but now I'm not sure on how we should proceed. I created a new branch (3.x) b/c I couldn't patch master where you've the 4.x development ongoing.
Maybe you could create the same branch on your repo so that I can create a pull request there? (apologize if I wrote some nonsense but I'm not very expert on github mechanics).

[rschristian]

Sorry, meant to do that earlier. It's now up at 3.x.x