Lucas_Werkmeister_WMDE added a comment.
There’s a fairly simple way to see what webpack is including in the built files (I’m checking the init module here because I’m doing this as part of investigating T233305 <https://phabricator.wikimedia.org/T233305>, but the app module should work similarly): node_modules/.bin/vue-cli-service build --mode development grep -F '!*** ' dist/data-bridge.init.js | wc -l I’ve pasted the full list at P9267 <https://phabricator.wikimedia.org/P9267> – mostly, it’s a whole bunch of `core-js` polyfills, including for things like `Function.prototype.bind` which we are really, //really// guaranteed to have already (by MediaWiki) and things like `RegExp.prototype[@@match]` that we never use directly. That list also doesn’t change if I trim the `.browserslistrc`, so I’m not sure where `@babel/preset-env` gets its browser list from that it thinks we need to be compatible with. I looked into the `bind` thing a bit further, and as far as I can tell the chain of dependencies is: - `./node_modules/core-js/library/modules/_bind.js` - is imported by `./node_modules/core-js/library/modules/es6.reflect.construct.js` - is imported by `./node_modules/core-js/library/fn/reflect/construct.js` - is imported by `./node_modules/@babel/runtime-corejs2/core-js/reflect/construct.js` - is imported by `./node_modules/@babel/runtime-corejs2/helpers/esm/construct.js` - is imported by `./node_modules/@babel/runtime-corejs2/helpers/esm/wrapNativeSuper.js` - is imported by: - `./src/data-access/error/EntityNotFound.ts` - `./src/data-access/error/EntityWithoutLabelInLanguageException.ts` - `./src/data-access/error/JQueryTechnicalError.ts` - `./src/data-access/error/TechnicalProblem.ts` Three of those last four classes are completely empty, by the way. But Babel still thinks their (implicit) constructors need to “wrap native super”, whatever that is, which requires //four// levels of `Reflect.construct` shims, which ultimately require `Function.prototype.bind`. And at no point in this chain are there any checks if the browsers list already includes the needed code – these are all regular, unconditional `require()` imports. As far as I can tell, `@babel/preset-env` is good for checking which parts of core-js your own code actually needs, and only including those parts – but then the various parts of core-js (and @babel/runtime-corejs2, apparently) still merrily depend upon one another, so that you still end up pulling in a lot of code that you don’t actually need. TASK DETAIL https://phabricator.wikimedia.org/T228857 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Lucas_Werkmeister_WMDE, Michael, Matthias_Geisler_WMDE, Aklapper, Pablo-WMDE, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
