Closed monsieurnebo closed 6 years ago
calcsam
commented
6 years ago It seems like the ability to choose the output folder would be sufficient, no? You could choose public/res as the folder.
Going to close this in favor of https://github.com/gatsbyjs/gatsby/issues/1878
m-allanson
commented
6 years ago @calcsam I think this request is slightly different. If I understand @monsieurnebo (please correct me if I have this wrong!), the aim is for Gatsby to be a bit neater with how it populates the public/ directory. So the name public/ is irrelevant, this is about how the contents of the directory are structured.
Moving all of Gatsby's auto-generated files into a subdirectory means that:
Here's an example using the build output for gatsbyjs.org with a new directory ___gatsby/ for storing static assets and Gatsby-specific files.
The top-level directory listing has gone from 451 items down to 28 items. Maybe it's just a small thing but I think this is a good win for Gatsby's usability without any major downsides.
The trade-off is that the user can no longer create any routes named ___gatsby, but I think that's ok? It could be configurable if necessary, but maybe better just to use an unusual name.
monsieurnebo
commented
6 years ago @calcsam @m-allanson is totally right. The output directory name customization would be useful for uniformity purpose (e.g. our CircleCI scripts are using a /dist/ for all our projects, except... Gatsby where we have to do an ugly mv public dist).
But no matter what this name is, the output files will be located at the hosting root, where we have the problem described in the current issue (and well summed up by m-allanson).
KyleAMathews
commented
6 years ago @m-allanson 👍
I think _gatsby is rather... ugly.
How about just /js/ as the subdirectory? That's quite common. If there's worries about conflicting with a path someday somewhere, we could also do /_js/.
monsieurnebo
commented
6 years ago @KyleAMathews I think /js/ is not explicit, it's hard to spot what this directory contains without be gatsby-friendly.
/gatsby/ (or /_gatsby/) is simple, intelligible and shouldn't cause conflicts.
KyleAMathews
commented
6 years ago /gatsby/ doesn't make sense because Gatsby can and does put files elsewhere e.g. /static/. I'd rather the folder name be based on functionality than imply that every file Gatsby will ever create will be in one folder which won't happen.
ptb
commented
6 years ago As a means of documenting one possible solution for this issue, I created an example repository to test. I'm not suggesting this is the best solution, but it might help to identify where paths may need to be changed.
m-allanson
commented
6 years ago @ptb nice! I'm loving the postinstall patch. For the curious, the public folder of @ptb's repo looks like this:
./
./chunk-manifest.json
./css/
./css/styles.css
./index.html
./js/
./js/a-appmain-21129a0ac3fa2757df65.js
./js/a-appmain-21129a0ac3fa2757df65.js.map
./js/b-commons-f7a0a7a05adacd8bdb22.js
./js/b-commons-f7a0a7a05adacd8bdb22.js.map
./js/c/
./js/c/c-93f95c4c-862182fbdb19e9f8504a.js
./js/c/c-93f95c4c-862182fbdb19e9f8504a.js.map
./js/p/
./js/p/p-e19cef0f-a0e39f21c11f6a62c5ab.js
./js/p/p-e19cef0f-a0e39f21c11f6a62c5ab.js.map
./static/
./stats.jsonIt's likely people will have their own opinions on how best to organise and name the files. We may need to pick something reasonably uncontroversial and stick with it.
I also think we should label this up as a v2 feature?
brotzky
commented
6 years ago @m-allanson or @ptb. Was this added to v2 or are you still looking for help on it? We'd love this feature for v2 if it's not implemented yet. I can investigate if it still needs help!
m-allanson
commented
6 years ago @brotzky help on this is still welcome!
brotzky
commented
6 years ago @m-allanson I'll take a look today! It's a hard requirement from one of our partners for them to accept our proposal to use Gatsby for the project.
KyleAMathews
commented
6 years ago @brotzky copying the files on build completion isn't an option?
brotzky
commented
6 years ago @KyleAMathews
I think I'll attempt using the postinstall script that was linked before and see how far I get. I am leaning towards not having this as part of Gatsby core.
Actually, this postinstall script is okay but depends on the internals of Gatsby so it's always a moving target. Maybe this is a worthwhile feature in core?
brotzky
commented
6 years ago I've opened a WIP PR that groups non-static files https://github.com/gatsbyjs/gatsby/pull/6285
m-allanson
commented
6 years ago Done in https://github.com/gatsbyjs/gatsby/pull/6346. :clap: Many thanks to @brotzky for doing all the hard work on this one 💯
Published as gatsby@2.0.0-beta.41
monsieurnebo
commented
6 years ago Great work!
The idea
It would be useful to regroup all the non-static files of the build into a subdirectory of
/public/.Something like:
Where
/res/would be the directory, that's a placeholder name.Why ?
You can have some situation where GatsbyJS's files aren't the only files on the hosting root. If you need to apply any operation on the Gatsby's files, it's a pain to target them and not other files. You have to look for:
app-...filescommons-...filescomponent--- ...filespath---...filesstyles.cssfileWe quickly can have something like 40 files to manage.
In our case, we want to invalidate the Cloudfront cache of Gatsby's files (on only them), and without the ability of using regex, it's a real pain...
It could be an interesting feature for v2 (along the ability of choosing the
publicdirectory name) :)