Hide component path in componentChunkName

[d4rekanguok]

Summary

Currently, the component path is exposed publicly via window.___chunkMapping:

___chunkMapping

"component---src-pages-blog-tags-js": [ "/component---src-pages-blog-tags-js-f81e0bfcd17d0da590e9.js" ]
"component---src-pages-contributing-events-js": [ "/component---src-pages-contributing-events-js-1c105d1d9312ff38c747.js" ]
...

I recently saw this SO question ^link & I think it's reasonable to hide these path, maybe only in production build.

Upon a bit of search, I found that the code here is responsible for generating:

gatsby/packages/gatsby/src/utils/js-chunk-names.js

Lines 11 to 12 in f59ba15

	const name = path.relative(directory, componentPath)
	return `component---${kebabCase(name)}`

I tested my idea with uuidv5:

  const NAMESPACE = `c8e9d964-7090-46ef-a1ed-8311a822b0e7`

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

All local unit tests passed & the site I tested this on seems to perform as expected.

___chunkMapping

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

What do you think? Should the component path in componentChunkName be hidden?

[davidhellsing]

+1

[d4rekanguok]

This would affect the caching of currently deployed Gatsby sites, so perhaps we can consider making it an opt-in thing? Like an option in gatsby-config.js maybe.

What do you think @pieh @wardpeet? Could this be considered, or is it a wont fix thing?

[sidharthachatterjee]

Just discussed with @pvdz @pieh and @m-allanson and we're unsure if this is a good default to have.

While we see the value in obfuscation, debugability is important to DX in general and human readable names should be preferred over hashes.

We'd like to avoid adding (yet another) config option to toggle this because that's an obligation to maintain. Let's hear what other folks have to say and we'll move forward accordingly.

Thank you for bringing this up!

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜

[youngmanalive]

+1

Is this still a possibility? The chunk names in the CDATA show up in SEO, which has caused multiple issues and headaches for us due to specific words that are forbidden through certain advertising policies.

[jamthos]

+1

Just would like to add that having the chunk names (acting as essentially a sitemap) visible in the source is not ideal. Would love to have some way to obfuscate these if possible. We use gatsby for making landing pages for example so there is not a lot of linking between the pages we generate. But competitors or anyone else can see more of our pages than we'd like if they cared to look. Thanks.