ChristopherBiscardi / gatsby-theme-examples

Examples of using gatsby themes
141 stars 11 forks source link

Enable running themes that have function gatsby-configs on their own #2

Closed signalwerk closed 5 years ago

signalwerk commented 6 years ago

When switching to the themes/gatsby-theme-blog folder and run yarn and yarn develop. I get an error. This would be helpful to work on the theme without having the site.

Error

ValidationError: "value" must be an object
error The site's gatsby-config.js failed validation
ChristopherBiscardi commented 6 years ago

Right now the typography plugin requires that we pass in the site's root directory as an argument and functions don't pass the validation for a site's gatsby-config (only for a theme). This should work if the config for the theme is an object and not a function.

Perhaps we should allow all gatsby-configs to be functions. Also we should have the typography plugin handle it's paths slightly differently to allow us to not need to pass through the root of the site as a config.

ChristopherBiscardi commented 5 years ago

In addition to updating the title, I'm considering a change to the ability to specify options that can be accessed in gatsby-config.js of a theme.

The issue with using functions as gatsby-configs is that they aren't first-class so if you try to yarn develop a theme that uses a function config (example shown below), it'll fail with the error in the top of this issue (failing validation).

// gatsby-config.js
module.exports = opts => ({
  plugins: [...]
})

This also presents an issue where if we add support for the function type config to gatsby, that we also have to add a way to pass the options in anyway.

I'm trying to explore an alternative API where the config is exposed as an object at all times, but haven't hit on anything I like more yet. Open to ideas here. The idea in my head is roughly dotenv like, where you can define a file that applies to a theme's options.

signalwerk commented 5 years ago

I'm probably not the right guy to ask for a clever API decision. To be honest I'm hardly understanding what I'm doing with my current theme 🙈 It works and I'm super glad you implemented it. I use it right now like you showed in your example without having the theme in a separate npm and for me it would be most important that at one point in time I could just have the most simple folder structure I can think of:

package.json     → theme & gatsby as npm. script like `gatsby develop --theme gatsby-theme-signalwerk`
[folder]         → .md(x) files
gatsby-config.js → optional if I wanna pass options

To later work easily on the theme (served via npm) it would be good to have the theme work standalone and not necessary the need being in a site-context.

But that's only me. Because I use the theme already now in a couple little side-projects and I would love just to update everything in the theme. Right now I need postcss.config.js, 404, index, ... as well in the repo. But I'm already super glad with what I got so far.

ChristopherBiscardi commented 5 years ago

sticking with the function approach, but that means we need to enable running themes on their own when they have function gatsby configs in core

jonnybot0 commented 5 years ago

@ChristopherBiscardi If you want to specify default theme options for developing a theme locally, why not just use JavaScript's options for specifying default arguments? e.g.

module.exports = ( themeOptions = { foo: "bar" } ) => {
    //Do stuff with options
    return {
        //Make more complex config here...
        plugins: []
    }
}

You could even require your default config from a separate config file in your theme if you didn't like putting it all in gatsby-config.js. I like that because it removes any magic; if you spend time re-implementing dotenv, that feels like a bit of a waste.