feat/plugin-options

[PaulieScanlon]

Hi friend, not entirely sure i understood your env conundrum but if i've understood correctly you wanted "users" to be able to pass api keys through plugin options as they normally would for all other types of Gatsby plugins, but the problem was these weren't then picked up by Serverless Functions in src/api

To circumvent the Gatsby build step which i don't think adds plugin options to the environment i've used the onPreInit extension point to grab the api_key value from the plugin options, set it on the environment which then makes it available for use later in the Serverless Function.

I've tested this with gatsby develop, perhaps i can add a build to the root package.json and test this with a gatsby build and gatsby-serve I'd like to see if there's a difference between the dev and prod env vars

Anyway, if this is what you were kind of looking for i'm happy to give it another go.

TODO

• Add api_key to plugin schema
• Determin name for api_key => apiKey || stripeApiSecret etc

[raae]

It doesn't solve the name-spacing issue that proper access to plugin options does. But it could be a work-around while waiting for proper support.

I started a discussion in the Gatsby repo, as Gatsby at least need to come up with a best practice that will be supported in the long run: gatsbyjs/gatsby#34047

[PaulieScanlon]

What's the name-spacing issue?

Is this because someone could in theory name an env var the same as the name you give to the env var in onPreInit?

[raae]

Yes, that would be it. In theory all plugin options could be env vars. But they are not, so I think this should be addressed and solved by Gatsby.

I have no problem coming up with a suitable work-around.

[PaulieScanlon]

It's a tricky one because Functions aren't part of the build step(s) so they aren't really aware of anything, including config options.

It would be good if each function made available an options param

handler (req, res, options) {}

Then you could grab secrets passed from options... However I'd worry that secrets would be exposed to clients where as all previous plugin options are kept server side.

[raae]

I think I might go with this solution.