Configurable output folder

[just-boris]

Currently the project is always generating content into public folder. It is fine for most cases, however some people have different project structure and want to change it.

How do you think about making this configurable via CLI argument or gatsby-config.js? For example:

gatsby build --output-dir my-static-website

public will remain default, of course.

[KyleAMathews]

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.

[just-boris]

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.

[KyleAMathews]

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

[just-boris]

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

[domparry]

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.

[just-boris]

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.

[KyleAMathews]

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.

[monsieurnebo]

@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?

[willdady]

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.

[KyleAMathews]

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.

[merlinstardust]

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?

[m-allanson]

Done in #4756. Thanks @Calderis!

[m-allanson]

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

[merlinstardust]

What issues did it have?

[m-allanson]

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

[benedictjohannes]

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.

[pavelloz]

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.

[hostingnuggets]

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

[bradley]

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

[stevemarksd]

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.

[digitalkaoz]

All discussions about simply moving things around in bash doesnt solve the Problem running gatsby in a readonly Filesystem (Lambda). so gatsby is simply not usable within cloudfunctions: so a big nope for gatsby. I recommend react-static (where it was clean to implement and contribute)

[loginov-rocks]

Agree, this is critical consideration preventing usage of Gatsby in read-only filesystems! Can be solved with more or less minor decision on configuration capabilities :(

[mzedeler]

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.

[pavelloz]

I guess we all agree :)

[danyim]

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.

I want to second this feature. Currently the output directory has a mix of cache-busting JS/CSS files and HTML, which makes it really hard to separate manually with scripts. For my particular use case, I deploy Gatsby via FTP, and when updating the site, it would be convenient to have a configurable output directory structure so that I know which directories to replace.

[kusaljay]

@danyim You're spot on with this!
I'm also seeking a solution to configure the output of the build directory.
Would be good to organise all those js, css, txt files in the root.
Has anyone figured out a solution for this?

[hostingnuggets]

Why do I get mails that this issue has been closed? This issue is not fixed and hence should not be closed. Thank you!

[LekoArts]

It wasn't closed, it was moved to Discussions.

[merlinstardust]

Why was this closed without further discussion?

[LekoArts]

It wasn't closed, it was moved to Discussions.

[mihanizm56]

any updates?

[martin-braun]

I thought Deploy Directions are meant to allow me to modify the output directory, but they are not.

I also have no idea why the issue was closed and converted to a discussion. In my opinion, there is nothing to discuss. To be able to configure the output path of a build should be a no-brainer, imho.

Now we are forced to make hacky stuff that works on all platforms, such as doing

npm i rsync -D

and modifying the npm run build script to do

gatsby build && rsync -av --delete public/ path/to/new/folder

[mzedeler]

As I understand it, it is just really tedious to accomplish this, so nobody has volunteered to add this feature.

[mathieudutour]

I did 2 years ago: #1878 (comment) #12501

[mzedeler]

Hmm. Thats disappointing. Maybe a first step could be some way of ensuring that plugins doesn't use a hardcoded output path?

[paulmelnikow]

I just read the two-year old response to this PR. The thing about it that’s pretty wrong is the characterization of the feature as “fringe.” Customizing the output path is a core feature, something which many, many developers would do under a range of situations, many of which are described in this thread. Building sites in /tmp in a lambda is an example where there’s not a reasonable workaround. I think it’s inappropriate to characterize the PR as addressing the fringe feature, when there are slews of developers who want to customize the output path for all kinds of different reasons.

[florent-andre]

Hi there !
Adding a new comment to a good old long thread...

I found a solution to get both gatsby dev & gatsby serve in parallel. This solution require docker & docker-compose (for simplicity), and implement this general idea :

• 2 containers are "mounted" to the gatsby-src (your code folder)
  • container 1 : gatsby-dev fully mount gatsby-src
  • container 2 : serv-gatsby is fully mounted BUT for the public, .cache and node_modules folders. Theses 3 ones are "mounted somewhere else".

For this solution working, gatsby clean have to be slightly changed because Docker's mounted folder can't be deleted.
The good news: with the help of fs-extra it's only changing .remove to .emptyDir

As of today solution this works pretty well.
If this docker level solution interest some of you folks, I can work on a minimal reproducible example for guidance.

[mathieudutour]

"This solution require docker & docker-compose (for simplicity)" 😄