Regroup non-static files into a public's subdirectory #3760
Labels
help wanted
Issue with a clear description that the community can help with.
Comments
|
It seems like the ability to choose the output folder would be sufficient, no? You could choose Going to close this in favor of #1878 |
|
@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 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 Current `public/` directory for gatsbyjs.orgProposed `public/` directory for gatsbyjs.orgThe 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 |
|
@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 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). |
|
I think How about just |
|
@KyleAMathews I think
|
|
|
|
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. |
|
@ptb nice! I'm loving the It'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? |
m-allanson
added
the
help wanted
|
@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! |
|
@brotzky help on this is still welcome! |
|
@m-allanson I'll take a look today! |
|
@brotzky copying the files on build completion isn't an option? |
|
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? |
|
I've opened a WIP PR that groups non-static files |
|
Great work! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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) :)The text was updated successfully, but these errors were encountered: