RFC - Plugins

[estrattonbailey]

Goals

• support both dev/prod plugins
• give access to config, context, internal actions API
• conform to context shape from update context API #35

Examples:

• head (already exists)

Questions:

• should these be instantiated on every render?
  • provides nice isolation, harder to write memory leaks
  • for static renders, only called once on render
  • for dynamic, would be created on every SSR (not ideal, but not necessarily bad, see: memory leak)
• some plugins will be useful for static and not dynamic, and vice versa
  • some will work for both in dev, but should not in prod (like file copying)
• what will be some common requests for plugins?
  • the more examples we have the better we can design the APIs around these

How

These will need to be processed either up front when we parse the user's config, or later on when we create the build context. The latter would be instantiating on every render (see above).

Plugins should probably be curried functions, so that we can pass context and internal APIs in:

// presta.config.js

// ...some library code for illustration purposes...
function createImageOptimizer (options)
  return (context, presta) => {
    return (userArgs) => {
      // handle user args in scope of context/presta API
    }
  }
}

// user configures where they want the plugins
export const plugins = {
  image: createImageOptimizer({ noCompress: true })
}

Notes

• since these are never bundled to the frontend, not worried too much about serverless bundle size
  • could treeshake the node bundle maybe?