Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide component path in componentChunkName #18791

Closed
d4rekanguok opened this issue Oct 18, 2019 · 7 comments
Closed

Hide component path in componentChunkName #18791

d4rekanguok opened this issue Oct 18, 2019 · 7 comments

Comments

@d4rekanguok
Copy link
Contributor

@d4rekanguok d4rekanguok commented Oct 18, 2019

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:

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
Copy link

@davidhellsing davidhellsing commented Oct 21, 2019

+1

@d4rekanguok
Copy link
Contributor Author

@d4rekanguok d4rekanguok commented Nov 2, 2019

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
Copy link
Contributor

@sidharthachatterjee sidharthachatterjee commented Nov 22, 2019

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
Copy link

@github-actions github-actions bot commented Dec 13, 2019

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
Copy link

@github-actions github-actions bot commented Dec 23, 2019

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
Copy link

@youngmanalive youngmanalive commented Jul 20, 2020

+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.

@thatjimmy
Copy link

@thatjimmy thatjimmy commented Feb 8, 2021

+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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants