Do you have a specific use case in mind? This has been discussed before but no one has come up with a concrete use case that justified adding a new option.

Every option we add to Gatsby makes the project more complex which has all sorts of long-term costs so unless something is really valuable, I'd rather people handle this sort of thing themselves e.g. just copy the files to the output directory you want or create a symlink. This could easily be turned into a plugin that people could install, etc.

Yes, I have a use-case. I am going to use Gatsby for a documentation part as a part of complex project. All static files (Gatsby output, plus some others) should be placed into one folder build, that will be deployed somehow later. In other words, the Gatsby output is only one subfolder in my setup.

So far I have worked this around in postbuild step, but it looks hacky:

"build": "gatsby build",
"postbuild": "mv public build/gatsby-subsite"

Adding configurable output folder will reduce this complexity and will help me not to move files around one more time.

Why do outputted files need to be in a folder named "build"?

Because I am composing the final result not only from Gatsby output, but also from some other sources. Gatsby will be responsible only for gatsby-subsite folder in the tree bellow:

build
├── assets
├── gatsby-subsite
│   └── generated-website-here...
└── index.html

I have a similar requirement, but I just use the CI tool to rename/move the folder as a post build step... I wouldn't say it's a gatsby concern this. Feels very CI to me.

For the time being, I have to do the same, that I have mentioned in the my comment above. But there are some downsides:

• Recently added feature Delete all html files in public as part of bootstrap #1811 obviously will not work, because files will be moved under a new location.
• I need to keep in mind, that there is a temporary public folder, that has to be present in .gitignore
• It requires an extra step of moving files around.

The general rule of thumb is only put stuff in core that can only be done in core and since this is more trivial to do in userland than core, I'm marking this #wontfix.

I'd love to see a plugin that implements a very efficient sync step to another directory e.g. default to rsync if available and use a node rsync-like implementation.

Re: #1811 rsync makes it easy to sync deletes as well.

@KyleAMathews We use a generic continuous integration configuration for all our projects, based on a /dist directory. It's unfortunate that a script is needed (for Gatsby based projects) in order to rename the output folder instead of a useful Gatsby option...

Any way of reconsider this feature?

Seems like a pretty trivial addition many people would find useful IHMO. Github pages expects the output to be in the root of the repository or in a docs/ directory.

Ok — I guess it is annoying enough / inefficient enough to have to copy files around to add this as an option.

Who wants to own the change? Public is hardcoded a number of places in the codebase. Also the new option would need documented, etc.

What's the update on this issue?

It looks like there are a couple pull requests ready but not merged yet.

What else do the PRs need to be ready?

Done in #4756. Thanks @Calderis!

#4756 had a few issues and was reverted. Reopening this.

What issues did it have?

build and develop weren't working in many cases, see the referenced issues in #4756

I would vouch the benefits of configurable output folder. Easiest use case is #4512 (differentiating dev and production build destination), very useful when opening production result in one browser tab (via gatsby serve or statically using localhost Apache/Nginx and trying out development build in another tab.

It would be great if there was an option to control output for at least html vs assets files.
I think it would be helpful to keep assets like css/js/fonts etc. (generally, referenced from html, webpack dynamic imports, etc.) in a separate directory inside public/ folder.

They often are moved to CDN (at least in my experience) and it would be much easier to have them grouped + properly configured urls with assetPrefix. This would remove a lot of post-build scripting and probably make intergations with a lot of platforms easier.

Any estimated time on when this feature will be implemented? I think it would be really useful.

I would also like this. My use case is that some clients want a Sanity studio client with Gatsby for the web app, where I run both through Netlify (e.g.; Netlify actually manages both the Sanity studio and Gatsby web app at a single URL rather than the more basic approach where they have separate domains). In order to make this a sane developer experience, the Sanity and Gatsby apps exist as separate sub folders in a lib directory, and both are built to a dist directory for production:

app/
  dist/          # gitignored and built for production
    studio/
    web/
  lib/           # development source code in version control
    studio/
    web/
  package.json
  ...etc

I have another use case:

I have multiple websites that derive from a main website. All that changes is a google analytics. I could copy paste the whole project, but doesn't make sense. So currently I need to deploy each website sequentially. Another problem is that keeps accumulating js files from variant A to variant B... so variant X will have all js from previous variants.

Would be cool to output to public/variantA, public/variantB.... especially when the only thing that changes is a small string.

They all get deployed to a different domain.

The reason I'd need this feature is to be able to run in parallel all the variant builds + reduce amount of js deployed.

My project is using automated build on github followed by publishing to github pages. The folder name on github is docs, so we have to move things, which is the current workaround. I just find it peculiar and an obvious code smell that such a basic thing can't be implemented easily. At the same time, I do acknowledge that such a change may require a lot of work due to the way the project was conceived to begin with. I just hope that someone can fix it at some point in the future.

I guess we all agree :)

any updates?