@timneutkens I think this is ready for a review.
I've made some changes to the original design that _seem_ to have paid off. The parenting relationships for traces of normal builds are applied more uniformly, resulting in more intelligible traces:
<img width="900" alt="Screen Shot 2021-01-29 at 12 53 47 AM" src="https://user-images.githubusercontent.com/5016978/106253732-ba321880-61cc-11eb-98fd-d45af5078273.png">
Hot-reloading is surfaced now, too. I will note, however, that we will want to dig in deeper and find out where the large portion of time at the beginning of hot-reload is spent. Example:
<img width="894" alt="Screen Shot 2021-01-29 at 12 53 28 AM" src="https://user-images.githubusercontent.com/5016978/106253828-e057b880-61cc-11eb-967d-46eaff31ecef.png">
Where did those 180 ms go? At the least, we can now track how long a hot-reload takes, and have a place to start with further investigation.
This picks up on the inlining work in https://github.com/vercel/next.js/pull/20598 to also include webpack loader inlining optimizations.
This includes:
* The dependencies of sass-loader
* resolve-url-loader
And for added benefit:
* babel-plugin-transform-define
* babel-plugin-transform-react-remove-prop-types
style-loader and css-loader didn't inline easily. Perhaps we can come back to these ones.
There's currently two bugs with the font optimization, but we'd really like to ship a stable version.
To unblock the stable release, we're **temporarily** reflagging this. It'll be unflagged on canary again!
Solves the following warning:
> (node:1484) [DEP_WEBPACK_MAIN_TEMPLATE_REQUIRE_FN] DeprecationWarning: MainTemplate.requireFn is deprecated (use "__webpack_require__")
This PR removes the modern mode experiment because:
- It does not yield meaningful bundle size wins when compared to other initiatives we've taken
- It's not compatible with webpack 5 (which we're upgrading to)
- It's currently broken and causes most apps to malfunction
- There's no champion currently owning the experiment
We can re-introduce this in the future when we'd like to make it a default for all Next.js apps.
Note: **Next.js still supports Differential Loading (`nomodule`) and does it by default.** This PR strictly removes the experimental modern _syntax_, and does not disable our existing modern/legacy polyfilling.
---
Fixes#19200Fixes#18960Fixes#14707Fixes#14465
We accidentally regressed back in 9.5 and dropped support for inline CSS comments. PostCSS always parses these as pass-through (and not a syntax error), which can cause problems when minifying.
Browsers do a similar thing and ignore the comments.
To ensure we generate valid CSS, this adds support for stripping the CSS comments from the build.
---
Fixes#15589Closes#17130
This upgrades to ncc@0.25.0 and fixes the previous bugs including:
* ncc not referenced correctly in build
* Babel type errors
* node-fetch, etag, chalk and raw-body dependencies not building with ncc - these have been "un-ncc'd" for now. As they are relatively small dependencies, this doesn't seem too much of an issue and we can follow up in the tracking ncc issue at https://github.com/vercel/ncc/issues/612.
* `yarn dev` issues
Took a lot of bisecting, but the overall diff isn't too bad here in the end.
This adds inlining for Babel and the Babel plugins used in next.
This is based to the PR at https://github.com/vercel/next.js/pull/18823.
The approach is to make one large bundle and then separate out the individual packages from that in order to avoid duplications.
In the first attempt the Babel bundle size was 10MB... using "resolutions" in the Yarn workspace to reduce the duplicated packages this was brought down to a 2.8MB bundle for Babel and all the used plugins which is exactly the expected file size here.
This will thus add a 2.8MB download size to the next package, but save downloading any babel dependencies separately, removing a large number of package dependencies from the overall install.
This is a prerequisite to being able to ncc inline the Babel dependencies in next.js.
The removal of preset-modules is based on replacing it with preset-env under `targets: { esmodules: true }`, as per the guidance from the package (https://www.npmjs.com/package/@babel/preset-modules):
> Starting from @babel/preset-env 7.9.0, you can enable the bugfixes: true option to get the same behavior as using @babel/preset-modules, but with support for custom targets. If you need to target browsers with native modules support (like this preset does), you can use targets: { esmodules: true }.
From the above, I'm pretty sure this is entirely a backwards compatible change, apart from the change to the runtime plugin list being visible. Perhaps @developit can confirm this as well.
To prevent FOUC, discussed in #10557 i need to store information about css file dependencies for chunk. Right now current implementation just throws away everything but js.
Can there be more than one css file in chunk? If no - code will be simplified.
closes#10557
This pull request edits the `BuildManifest` that is sent to `/_document` instead of modifying a single input array to decouple its implementation details.
Optimally, we'd eliminate the `files` key all together.
---
Related to #16182
- Using `namedChunks` where possible, this will also allow for faster access to the chunks as we no longer have to look them up like we did before using `find`
- Using the new asset hooks introduced in the latest webpack beta
- Using the new externals function signature
