Next.js: Eliminate `core-js` from “Hello World” Next.js applications
As discussed with @Timer, core-js is not needed in most cases. He can add in more context here.
timneutkens
All 29 comments
@timneutkens I'm assuming caching is the reason core-js is used in full here, rather than going with @babel/preset-env's "useBuiltIns":"entry" option?
/cc @keanulee
developit
on 8 Apr 2019
Is it currently possible not to include core-js in the compiled JS files at all?
I think I don't need it, my app only targets the evergreen browsers.
mmiszy
on 16 Jul 2019
As an alternative, you could consider bumping up to using core-js 3 (via babel) which allows tree-shaking and targeted inclusions: https://github.com/zloirock/core-js#babelpreset-env
merrywhether
on 25 Jul 2019
There's also a great external polyfill service (https://polyfill.io/v3/) which we use extensively in my org (self-hosted in our case) to avoid unnecessary bloat over-the-wire. Would be interesting to consider a Next that lists what might need to be polyfilled (either via that service or hard-coded polyfills brought by the user) but does not necessarily include its own solution.
merrywhether
on 25 Jul 2019
I would love to remove core-js completely from my bundles.
I'm importing barely any JS at all other than React and Next.js is still loading the entirety of core-js which seems incredibly wasteful to me, especially for my uses case where I don't care about support for older browsers.
fabiospampinato
on 27 Sep 2019
any solutions ?
popuguytheparrot
on 1 Oct 2019
@merrywhether I am curious to know how are you guys using polyfill.io with the next.js project. That's what I am trying to do in a project but didn't found good examples yet.
vjs3
on 17 Oct 2019
@vjs3 I'm using it by extending Document and placing a script tag before the next script:
import Document_, { Head, Main, NextScript } from 'next/document'
const polyfillFeatures = [
'default',
'Array.prototype.find',
'Array.prototype.includes',
]
export default class Document extends Document_ {
render () {
return (
<html>
<Head />
<body>
<Main />
{/* Just the polyfills you need for your site, tailored to each browser. */}
<script type='text/javascript' src={`https://cdn.polyfill.io/v2/polyfill.min.js?features=${polyfillFeatures.join(',')}`} />
{/* Site Scripts */}
<NextScript />
</body>
</html>
)
}
}
LinusU
on 18 Oct 2019
@vjs3 We do almost the same as @LinusU, except we add an additional entry in <Head /> to generate a <link rel="preload" as="script href={polyfillHref}" /> to help the browser get the script sooner and speed up app boot.
merrywhether
on 19 Oct 2019
Thanks a lot @LinusU and @merrywhether for your detailed explanation. I am using the same implementation as you suggested @merrywhether.
vjs3
on 25 Oct 2019
Any solutions about removing core-js from bundles? It's really not needed in most cases!
MaxSvargal
on 16 Dec 2019
module.exports = { experimental: { modern: true } } would help a bit.
timneutkens
on 16 Dec 2019
@timneutkens in a lastest version?
popuguytheparrot
on 16 Dec 2019
Canary, note that it's experimental.
timneutkens
on 16 Dec 2019
@timneutkens I can't confirm that. Even if I set modern:true, core-js remains in the bundles (both the module and nomodule bundles).
Another source of overhead is the polyfills.js file which currently (as of version 9.2.0) contains fetch and url polyfills, they are not needed in modern browsers either.
wereHamster
on 18 Jan 2020
Another source of overhead is the polyfills.js file which currently (as of version 9.2.0) contains fetch and url polyfills, they are not needed in modern browsers either.
This is not loaded in modern browsers by means of the nomodule property.
timneutkens
on 18 Jan 2020
I stand corrected. I was only looking at the output from the bundle analyzer which shows two polyfills bundles. Both are generated but the polyfills-XXX.module.js is not actually being loaded into a modern browser.
bundle analyzer screenshot of an empty next.js v9.2.1-canary.2 app with modern:true
wereHamster
on 18 Jan 2020
I did a bit of investigation why corejs ends up inside the bundles. It has nothing to do with the webpack or babel configuration that is used for the app, so there is nothing we (the users of next) can actually do to change the current situation.
The actual reason though is pretty straight forward: It's pulled in through the babel runtime polyfills which are used in the next/dist/client/* modules. For example, consider "next/router", which through its dependencies (next/router.js -> next/dist/client/router.js) eventually imports "@babel/runtime-corejs2/helpers/interopRequireWildcard", "@babel/runtime-corejs2/helpers/interopRequireDefault", "@babel/runtime-corejs2/helpers/extends", and "babel/runtime-corejs2/core-js/object/define-property". These are CJS modules, so therefore not treeshakeable, and all end up in the bundle. Together these are ~47kB, which pretty closely matches the ~49kB that I'm seeing in the output from the bundle analyzer.
I think the only solution is to not publish next/client/* as commonjs but instead publish those modules as ESM, and then process them through webpack so that babel can inject the appropriate polyfills. And also not inject the babel runtime polyfills in those published modules. It should be up the the end consumer of next to decide which polyfills are need, this is not something that the next team can decide at the time they publish the next package to npm.
wereHamster
on 18 Jan 2020
Any update on this one? Core-js takes an awful lot of space in my bundles, included in the same chunk as some src code:
Thanks!
Danetag
on 23 May 2020
Actually, using this babel config seems to resolve it:
.babelrc
{
"presets": [
[
"next/babel",
{
"preset-env": {
"useBuiltIns": "entry",
"corejs": "3.6"
}
}
]
]
}
.browserslistrc
last 2 versions
> 0.25%
not dead
not IE 11
@Danetag Do you import "core-js"; anywhere in your project? Because if not, you are not loading the core-js polyfills at all, not even those required for the browsers which match your browserslistrc.
See the documentation for useBuiltIns.
wereHamster
on 24 May 2020
This has actually been fixed! Any core-js present in your application is due to your application code or a dependency.
Timer
on 24 May 2020
https://github.com/zeit/next.js/issues/6931#issuecomment-633158748
FWIW don't make these changes unless you know the exact semantics of how it works, by adding this it adds every core-js polyfill needed into the bundle sent to all browsers which is not needed as Next.js automatically polyfills older browsers covered by that setting and only loads that polyfill JS in browsers that don't support <script type="module"> (legacy browsers)
timneutkens
on 24 May 2020
@timneutkens I'm no Babel expert, and you're right, according to the doc it's supposed to do exactly what you described.
But for some reasons, it seems that core-js is removed with "useBuiltIns": "entry", but not "useBuiltIns": "usage".
With "useBuiltIns": "usage":
With "useBuiltIns": "entry":
I'm confused 🤷 If you have any tips, that would be great!
Danetag
on 24 May 2020
Use this babelrc:
{
"presets": [
[
"next/babel"
]
]
}
All the config you had is not needed and can only cause larger bundles where not needed.
timneutkens
on 24 May 2020
@timneutkens Awesome! Thanks you 🔥
Danetag
on 24 May 2020
@timneutkens Now I remember the context of why we added this custom config. We just dropped the support for IE 11, but it wasn't the case at the beginning of the project. We encountered this error in IE console:
"Object doesn't support property or method 'repeat'"
And the only way to make it work was this update. Anyway, it's a separate issue that we don't have anymore, but maybe something to be aware of!
Thanks again 👍
Danetag
on 24 May 2020
Now I remember the context of why we added this custom config. We just dropped the support for IE 11, but it wasn't the case at the beginning of the project. We encountered this error in IE console:
When was that? We changed the way Next.js polyfills legacy browsers a while back and the specific case you're seeing should be fixed already 👍
timneutkens
on 24 May 2020
@timneutkens About 4 weeks ago, using next v9.3.4, Node v12.16.1
Danetag
on 24 May 2020
Related issues
iamstarkov
·
119Comments
Vista1nik
·
55Comments
Timer
·
87Comments
baldurh
·
74Comments
poyiding
·
73Comments
Most helpful comment
I did a bit of investigation why corejs ends up inside the bundles. It has nothing to do with the webpack or babel configuration that is used for the app, so there is nothing we (the users of next) can actually do to change the current situation.
The actual reason though is pretty straight forward: It's pulled in through the babel runtime polyfills which are used in the next/dist/client/* modules. For example, consider "next/router", which through its dependencies (next/router.js -> next/dist/client/router.js) eventually imports "@babel/runtime-corejs2/helpers/interopRequireWildcard", "@babel/runtime-corejs2/helpers/interopRequireDefault", "@babel/runtime-corejs2/helpers/extends", and "babel/runtime-corejs2/core-js/object/define-property". These are CJS modules, so therefore not treeshakeable, and all end up in the bundle. Together these are ~47kB, which pretty closely matches the ~49kB that I'm seeing in the output from the bundle analyzer.
I think the only solution is to not publish next/client/* as commonjs but instead publish those modules as ESM, and then process them through webpack so that babel can inject the appropriate polyfills. And also not inject the babel runtime polyfills in those published modules. It should be up the the end consumer of next to decide which polyfills are need, this is not something that the next team can decide at the time they publish the next package to npm.