Make `inputs` required

If a plugin is using config values a.k.a inputs the plugin author must define the name, types, a description of the fields, & a when property. This will help ensure plugins self-document & give us a clear path forward for a world-class DX.

Required input fields

The soon to be renamed config key a.k.a inputs should have these required fields.

• type (required) Type of input accepted
• description (required) text used for visual displays in CLI/UI to help users input/find/validate values
• when (required) When specifies when the configuration value is needed & where it will be used

Below is an example. The full API spec is outlined here

function netlifyPlugin(config) {
  return {
    name: 'netlify-plugin-example',
    inputs: {
      foo: {
        /* Type of input accepted */
        type: 'string',
        /* text used for visual displays in CLI/UI to help users input/find/validate values */
        description: 'Number required for service to function',
        /* When specifies when the configuration value is needed & where it will be used */
        when: 'onInit',
      },
    },
    /* Lifecycle methods */
    onInit: async ({ pluginConfig }) => {
      console.log(pluginConfig.foo)
    },
  }
}

DX

It would be a cool bonus if we warn plugin authors if they are trying to access values from pluginConfig that have not been defined yet. Perhaps via JS proxy

Rollout

Rolling this out will be a breaking change for most plugins that have been written, we will need to coordinate & update everything we have the control to update to accommodate these new required fields.

Related issues:

• https://github.com/netlify/build/issues/724
• https://github.com/netlify/build/issues/746

[erquhart]

Ironically, considering the title of the issue, note that my previous example shows inputs as optional. This is because a plugin could conceivably run without inputs, so optional would seem the natural choice. The goal of this issue is to ensure that user inputs can’t be accessed by the plugin without being properly defined - we accomplish that by only passing defined inputs to the plugin.

[erquhart]

It will be breaking, but agreed that it doesn’t seem to be in use for current plugins.

We should also add:

• select: JSON type string, HTML <select>

Nice to haves (not in scope for beta):

• select: JSON type string or array (for multi-select), HTML <select>

Also noticed that the original spec has a displayName - my label proposal would replace that.