Closed signalwerk closed 5 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.
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.
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.
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
@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.
When switching to the
themes/gatsby-theme-blog
folder and runyarn
andyarn develop
. I get an error. This would be helpful to work on the theme without having the site.Error