This introduces a new `<Html>` tag for a custom `Document` so that we can correctly toggle the `amp` flag (among other things in the future ... maybe).
This is already "tested" through every other test & the AMP validator -- but let me know if we want explicit tests.
Currently, `getBaseWebpackConfig` is marked async, but it doesn't await anything or otherwise return a Promise. Please correct me if I am wrong, but it looks like it can be made synchronous.
After talking with @timneutkens it was decided it'd be more streamlined to replace the onDemandEntries WebSocket with an alternative. Using the EventSource connection gives us these benefits over the WebSocket one:
- less code needed
- no extra server running
- no extra config for onDemandEntries
* fix(launch-editor): resolve filename including current working directory
* refactor: handle when fileName is already absolute
* feat: use Next.js dir instead of process.cwd()
Arguments that held the same name as one of the default commands were filtered out, causing issues.
For example `next build build` would get rid of the second `build` parameter.
Fixes#6263
Fixes#5347
The main issue is that we were waiting only 1 level of dynamic imports, so the dynamic imports nested inside other dynamic import files were not awaited. This would cause either a flash of loading states or you wouldn't see the loading state (because of preload) but it would then show a hydration warning in development.
Thanks to @arthens for providing the reproduction that I modelled the tests after.
* Remove usage of WebpackBar and Friendly Errors
* Add new clearConsole helper
* Add new simplified output for development mode
* Add an explicit bootstrapping mode
* Add missing returns
* Use existing output style
* Adjust first output to say Waiting on
* Only print URL if present
After discussion, I added falling back to fetch based pinging when the WebSocket fails to connect. I also added an example of how to proxy the onDemandEntries WebSocket when using a custom server. Fixes: #6296
Closes: #6244
This will block the following keys:
```
NODE_.+
__.+
```
There doesn't seem to be a way to simulate a failed build or else I'd add tests for it.
