blocked on "wait until bundle finished: /"

[nathanaelle]

What is the current behaviour?

the browser doesn't provide any reply from npm run dev.
the last message from npm run dev is "wait until bundle finished: /"

Steps to Reproduce

1. npm cache clean --force
2. npx preact-cli create typescript test
3. npm run dev
4. curl http://127.0.0.1:8080/

What is the expected behaviour?

the default webpage for / provided by a vanilla installation.

[rschristian]

Hmm, I cannot reproduce.

The only thing I can think of is the TS test directory error. With React v18 having came out, there's an issue with Enzyme in that it pulls down incompatible types as it specifies "@types/react": "*". It shouldn't block the build, and I can use curl to get the template regardless, but maybe try removing the tests directory from tsconfig.json's "includes"?

Can you provide the output of npx preact info in your project? Just to make sure there's no weird dependency version issues.

[nathanaelle]

hi,

I've made the following test :

1. npx preact-cli create default test
2. npm run dev
3. curl http://127.0.0.1:8080/

and … curl is waiting and npm run dev displays the same message "wait until bundle finished: /"
I tested /profile … and same result.

npm run build runs without any issue and opening the index.html in a browser is fine with the expected content.
this test was also done for the typescript version and the index.html contains the expected result.

the npm cache clean --force came from some one who has a similar issue.

because you've said you cannot reproduce, I've tried on another computer wich was already used for some dev with preact few months ago.
I tried npx preact-cli create default test1 … and same issue.

it was the first time I've used preact on the first computer.

npx preact info prints on both computers :

  npmPackages:
    preact: ^10.3.2 => 10.7.1
    preact-cli: ^3.0.0 => 3.3.5
    preact-render-to-string: ^5.1.4 => 5.1.21
    preact-router: ^3.2.1 => 3.2.1

does that means npx installed older version of preact and preact-cli even on the new computer (aka the one used yesterday) ?

[rschristian]

You've stripped out the environment info, please don't. preact info outputs that for a reason.

Edit: No, your Preact/CLI versions seem up-to-date and fine. A global install of an older version of preact-cli could be problematic, but it wouldn't cause issues if you're using NPM scripts (which you are).

[nathanaelle]

Environment Info:
  System:
    OS: macOS 12.3.1
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  Binaries:
    Node: 18.0.0 - /usr/local/bin/node
    Yarn: 1.22.18 - /usr/local/bin/yarn
    npm: 8.6.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 101.0.4951.41
    Firefox: 99.0.1
    Safari: 15.4
  npmPackages:
    preact: ^10.3.2 => 10.7.1
    preact-cli: ^3.0.0 => 3.3.5
    preact-render-to-string: ^5.1.4 => 5.1.21
    preact-router: ^3.2.1 => 3.2.1

and for the new computer, the only difference is :

CPU: (8) arm64 Apple M1

[rschristian]

Thanks. Is there no output in your terminal besides wait until bundle finished: /?

[nathanaelle]

I've edited package.json to add --clear=false

so the full capture :

% time npm run dev

> [email protected] dev
> preact watch --clear=false

 Build  [                    ] 0% (0.0s) compiling<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:8080/
<i> [webpack-dev-server] On Your Network (IPv4): http://xxxxxxxxxxx:8080/
<i> [webpack-dev-server] On Your Network (IPv6): http://[xxxxxxxxxxx]:8080/
<i> [webpack-dev-server] Content not from webpack is served from '/Users/mouns/zz_destroy/test1/src' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'

<i> [webpack-dev-middleware] wait until bundle finished: /
^C<i> [webpack-dev-server] Gracefully shutting down. To force exit, press ^C again. Please wait...
npm run dev  8,58s user 0,83s system 13% cpu 1:07,87 total

As you can read, I've waited around 1 minute (without any answer) before the ^C

EDIT : it was tested on the default javascript version

[rschristian]

Cheers, thanks. Should also just be able to scroll up, that's all the clear does.

I am on Linux, and Node v14 as it doesn't seem v18 is available via my distribution method of choice yet. We can keep this open but without a clear way to reproduce for the moment there's nothing I can personally do.

I'm guessing by the cache clearing step you've listed, you've already ran into those same threads I'm reading where cache issues might've been at play? Not sure why that'd be the case here. Weird issue.

[nathanaelle]

I know for --clear=false ;) I've used it for an easy copy-paste of the output.

so, if you use linux …

openJS foundation provides snap package ( https://snapcraft.io/node )

node 16 ( current LTS )

npx preact-cli create default test is fine with node 16.

node 17

0. boostrap a ubuntu linux vm
1. sudo snap install node --channel=17/stable --classic
2. node -v ( 17.7.1 )
3. npx preact-cli create default test
4. npm run dev

cant run curl because npm run dev exits immediatly.

and :

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:135:10)
    at module.exports (<privatepath>/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (<privatepath>/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (<privatepath>/node_modules/webpack/lib/NormalModule.js:471:10)
    at <privatepath>/node_modules/webpack/lib/NormalModule.js:503:5
    at <privatepath>/node_modules/webpack/lib/NormalModule.js:358:12
    at <privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
    at <privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:236:3
    at runSyncOrAsync (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
    at iterateNormalLoaders (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
    at Array.<anonymous> (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (<privatepath>/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:55:16)
    at <privatepath>/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:91:9
 Build  [==                  ] 10% (0.5s) building✖ ERROR Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:135:10)
    at module.exports (<privatepath>/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (<privatepath>/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (<privatepath>/node_modules/webpack/lib/NormalModule.js:471:10)
    at <privatepath>/node_modules/webpack/lib/NormalModule.js:503:5
    at <privatepath>/node_modules/webpack/lib/NormalModule.js:358:12
    at <privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
    at <privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:236:3
    at context.callback (<privatepath>/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at <privatepath>/node_modules/babel-loader/lib/index.js:59:71

node 18 ( snap channel latest/edge )

same as node 17.

thanks for your help, and I hope my tests will provide insights to you.

[rschristian]

I'm aware of snap packages, just not my method of choice, so I won't be using them.

Node 17 is known bad on Webpack 4 (see webpack/webpack#14532), with nothing that can really be done about it (though users can add $ NODE_OPTIONS=--openssl-legacy-provider ...)

same as node 17.

Are you saying you're now seeing the same error as Node 17, rather than the build being stuck?

[nathanaelle]

same as node 17.

Are you saying you're now seeing the same error as Node 17, rather than the build being stuck?

On linux, node 17 and node 18 gave me the same error.
On macos, mode 18 gave me the reported error.

Now, I use node 16.

thank you for your help :)

[rschristian]

In that case, this sounds like a duplicate of #1579