How to find source of a module in the production bundle?
See original GitHub issueSummary
I am setting up a small GatsbyJS blog/personal-site with gatsby-transformer-remark
for markdown posts and gatsby-theme-mdx-deck
for slides. I have been trying to reduce my total bundle size. It was 2MB+ at the start, it’s now less than 900kb. Updating Gatsby (as suggested in #19957) finally reduced my initial js size to ~400kb.
I am now trying to get rid of large modules, and lodash stands out right now and I can’t figure out where it is coming from:
I also am not sure if gatsby-theme-mdx-blog
should be in the main app bundle as it’s used only under the /slides
subpath.
Relevant information
I added babel-plugin-transform-imports
to my babelrc but the full lodash module still remains in the bundle. I tried the gatsby-plugin-lodash
with the same results.
// .babelrc.js
module.exports = {
plugins: [
[
"babel-plugin-transform-imports",
{
lodash: {
transform: "lodash/${member}",
preventFullImport: true,
},
},
],
],
};
What I am trying to figure out is where it is coming from? I tried webpack visualizer and various tools but the way gatsby generates the js they weren’t of much help.
You can see the current state of the project at https://github.com/rohit-gohri/blog/tree/685a9cbf9c5b783c49dd588418458bd6b71dd80f
Environment (if relevant)
System:
OS: Linux 4.15 elementary OS 5.1 Hera
CPU: (8) x64 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
Shell: 5.4.2 - /usr/bin/zsh
Binaries:
Node: 12.2.0 - ~/.nvm/versions/node/v12.2.0/bin/node
Yarn: 1.22.4 - ~/.yarn/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v12.2.0/bin/npm
Languages:
Python: 2.7.17 - /usr/bin/python
Browsers:
Chrome: 80.0.3987.149
Firefox: 72.0.2
npmPackages:
gatsby: ^2.20.12 => 2.20.12
gatsby-image: ^2.3.1 => 2.3.1
gatsby-plugin-draft: 0.0.5 => 0.0.5
gatsby-plugin-eslint: ^2.0.8 => 2.0.8
gatsby-plugin-feed: ^2.4.0 => 2.4.0
gatsby-plugin-manifest: ^2.3.2 => 2.3.2
gatsby-plugin-netlify: ^2.2.0 => 2.2.0
gatsby-plugin-offline: ^3.1.2 => 3.1.2
gatsby-plugin-react-helmet: ^3.2.0 => 3.2.0
gatsby-plugin-sass: ^2.2.0 => 2.2.0
gatsby-plugin-sharp: ^2.5.3 => 2.5.3
gatsby-plugin-transition-link: ^1.18.0 => 1.18.0
gatsby-plugin-webfonts: ^1.1.2 => 1.1.2
gatsby-plugin-webpack-bundle-analyser-v2: ^1.1.8 => 1.1.8
gatsby-remark-embedder: ^1.16.0 => 1.16.0
gatsby-remark-external-links: ^0.0.4 => 0.0.4
gatsby-remark-github: ^2.0.0 => 2.0.0
gatsby-remark-images: ^3.2.1 => 3.2.1
gatsby-remark-relative-images: ^0.3.0 => 0.3.0
gatsby-remark-social-cards: ^0.4.1 => 0.4.1
gatsby-source-filesystem: ^2.2.1 => 2.2.1
gatsby-theme-mdx-deck: 3.0.13 => 3.0.13
gatsby-transformer-remark: ^2.7.0 => 2.7.0
gatsby-transformer-sharp: ^2.4.2 => 2.4.2
npmGlobalPackages:
gatsby-cli: 2.10.0
File contents (if changed)
gatsby-config.js
: https://github.com/rohit-gohri/blog/blob/685a9cbf9c5b783c49dd588418458bd6b71dd80f/gatsby-config.js
package.json
: https://github.com/rohit-gohri/blog/blob/685a9cbf9c5b783c49dd588418458bd6b71dd80f/package.json
gatsby-node.js
: https://github.com/rohit-gohri/blog/blob/685a9cbf9c5b783c49dd588418458bd6b71dd80f/gatsby-node.js
gatsby-browser.js
: https://github.com/rohit-gohri/blog/blob/685a9cbf9c5b783c49dd588418458bd6b71dd80f/gatsby-browser.js
gatsby-ssr.js
: https://github.com/rohit-gohri/blog/blob/685a9cbf9c5b783c49dd588418458bd6b71dd80f/gatsby-ssr.js
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (8 by maintainers)
While trying to reproduce it I fixed it, there was a
require("lodash")
instead of an import at https://github.com/rohit-gohri/blog/blob/174f59a7dcb8a6c9d5dc38ac6cd821956d2aa164/src/utils/safePrefix.js#L2 so babel-transform-imports didn’t change it.But the actual problem isn’t that I couldn’t get rid of it, it’s that there isn’t tooling support to find which module/file is a chunk coming from. Or if there is an easier way to know that please let me know?
Loading the webpack stats file in a visualiser just tells me that all modules are from node_modules, there isn’t a mapping to actual src files (even if just names match that’ll be beneficial)
Within your site,
lodash
is being imported here:You could discontinue the usage of the library (especially for
_.map()
since its performance is identical tomap()
according to this experiment) to reduce your bundle sizes.