Rename webpack/gatsby chunkmapping strings

user_210578 0
Viewed 683

When building our production app in Gatsby, I see something like this:

window.___chunkMapping={
  "app":[],
  "component---src-templates-page-tsx":[],
  "component---src-templates-pages-newsletter-tsx":[]
}

Is it possible to hash these paths instead of printing them out? We don‘t want to expose too much from what is happening in the back.

I tried setting these configs in webpack:

output: {
  filename: `[chunkhash:2][contenthash:5].js`,
  chunkFilename: `[chunkhash:2][contenthash:5].js`,
},

And it successfully hashes .js files but not the template paths.

gatsby webpack node.js javascript
1 Answers

I upvoted this question when I first saw it, I think it's definitely should be done in production build.

Unfortunately, componentChunkName (the template path in question) is generated by Gatsby in createPage & not handled by webpack.

The code that generates componentChunkName is over here: github

I tried to modify the code as follow:

    const { kebabCase } = require(`lodash`)
    const path = require(`path`)
+   const uuidv5 = require(`uuid/v5`)
    const { store } = require(`../redux`)

    const generateComponentChunkName = componentPath => {
      const program = store.getState().program
      let directory = `/`
      if (program && program.directory) {
        directory = program.directory
      }
      const name = path.relative(directory, componentPath)

-     return `component---${kebabCase(name)}`
+     return process.env.NODE_ENV === `production`
+       ? `component---${uuidv5(name, uuidv5.URL)}`
+       : `component---${kebabCase(name)}`
    }

    exports.generateComponentChunkName = generateComponentChunkName

This successfully hides all the component names in production build:

app: Array [ "/app-e593b3d93932ed3a0363.js" ]
"component---11d478fe-6a55-579c-becf-625ab1e57cf4": Array [ "/component---11d478fe-6a55-579c-becf-625ab1e57cf4-76c90ae50035c52657a0.js" ]
"component---15c76861-b723-5e0a-823c-b6832aeeb0a0": Array [ "/component---15c76861-b723-5e0a-823c-b6832aeeb0a0-18eb457ba6c147e1b31b.js" ]
...

None of the local unit tests failed, my clicking-around-until-something-breaks test also hasn't yielded any errors. I might submit a PR later today to see if the maintainers have some insights on why this is not a good idea.

Edit: I opened an issue instead: github, you can subscribe to the issue to see how it resolves.

user_103409700
Related