Allow "gatsby new" to install from a subdirectory in e.g. a monorepo

[KyleAMathews]

This is something we've considered for a long time but with the recent release of themes, has become a lot more pressing as themes are best developed with a yarn workspace that includes the theme & its starter — but it's a pain to have to copy out the starter to another repo so people can easily create sites. Much more ideal is if gatsby new could know to clone the monorepo but to create the site from the starter directory.

This would require some sort of metadata to be in the root directory that gatsby new would read.

This thread is to brainstorm some ways to do this and then we should write an RFC before implementation.

One easy way to do this is to add a gatsby key to the root package.json e.g.

{
  "gatsby": {
    "starterDirectory": "starter"
  }
}

[KyleAMathews]

/cc @gatsbyjs/themes @gatsbyjs/core

[pieh]

I think key in root package.json could be either limiting (allow only single starter in repo) or cumbersome (you could define multiple starters, but then user has to select which one he actually wants)

Alternative that I don't know if I like yet, is to be able to define directory path in gatsby new command as arg.

---

Another problem that needs to be solved is checking out just subdirectory.

There is "Sparse checkout" in git, but it still will actually fetch everything and only checkout subset locally. Ideally we could use partial clone, but github "git" server doesn't support --filter switch.

So in the end users will have to fetch everything (well we can make it shallow - but still full tree) - so this will work for monorepos dedicated to themes development - but we couldn't really migrate official starters from gatsbyjs/gatsby-stater-X to use gatsbyjs/gatsby repo.

[KyleAMathews]

Yeah I only see this a solution for monorepos with one theme and starter. So for people doing more, they'd still need the GitHub action.

Which I think is pretty reasonable. If you're investing more, setting up actions isn't too bad. But if you want to whip out child themes and you're perhaps more of a designer than developer, this would help a lot.

[jxnblk]

This is probably similar to what @pieh is talking about, but would we not want to support specifying a path from the CLI so that something like gatsby new gatsbyjs/gatsby/starters/blog would work if there's a package.json file, even if it would mean cloning an entire repo?

My guess is that most repos wouldn't be as large as Gatsby, and it seems like a nice, zero-config way to add a starter to any project. There might be a whole slew of problems with something like this that I'm not thinking about, though

[gatsbot[bot]]

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! 💪💜

[vpicone]

Has there been any more thought about this? Would be a big quality of life fix for the most common theme development workflow.

[muescha]

a better sparse checkout is now in Git 2.25:
https://github.blog/2020-01-13-highlights-from-git-2-25/

[tx0c]

any update on this? at almost end of 2021

as the Official Themes repo https://github.com/gatsbyjs/themes/tree/master/starters has a few starters, then to start a new site with i18n support, the natural way to start is:

$ gastby new example-i18n https://github.com/gatsbyjs/themes/tree/master/starters/example-i18n