David Wells
David Wells
Yeah maybe these types of plugins will run on a `provisioning` step. They might expose functions like: ```js function mongoPlugin(conf) { return { create: ({ netlifyConfig }) => { console.log('idempotent...
For right now we can use the lifecycle in place. ``` function mongoPlugin(conf) { return { init: () => { // create idempotent mongoDB instance }, } } ```
TODO look into the mongoDB complexity Also outputs.
Not sure I follow. How does this materialize? A `extends` key on a plugin declarations in `netlify.yml|toml`?
I see. This would make reading the build instructions more difficult (unless you understood what extend does under the hood and where it resolves from) For now we should keep...
 Let's hold off on this for right now. I will show you how it's possible in userland
@bahmutov that code is correct. The issue right now is the deployment is actually happening outside of the lifecycle and the real site is not yet live when your code...
Yeah the site would need to get served with something like https://www.npmjs.com/package/serve You can get the build directory like so: ```js module.exports = function netlifyPlugin(pluginConfig) { return { postBuild: ({...
There are a couple cases to consider: - Plugin authors might want *all* lifecycle methods to run in parallel by default - Plugin authors might want *specific* (not all) lifecycle...
^ this looks good. I like having the same syntax in both spots. ## Code ```js module.exports = function exampleEverythingParallel() { return { parallel: ['init'], // only init is parallel,...