Syntax for `plugins` configuration property

At the moment the syntax for the plugins configuration property is:

plugins:
  - netlify-plugin-functions:
      enabled: false
  - ../../my-plugin:
      enabled: true

I think representing a collection by using first an array then a single-property object is a little uncommon and adds one level of indentation. Also using file paths as object keys feels a little wrong (or is that just me?).

What do you think of the following alternative?

plugins:
  - name: netlify-plugin-functions
    enabled: false
  - path: ../../my-plugin
    enabled: true

On one hand it requires typing one more word. On the other hand, I think this is visually clearer and feels simpler to grasp for the end user.

This also allows us to separate different loading strategies into different properties. IMHO a single polymorphic property is harder to learn that several monomorphic properties. At the moment we only have two loading strategies (by name and by path) but this would make adding more easier.

Another advantage is, if we were to pass the list of plugins to the end user, we would probably normalize it to the above shape anyway. It would be then be easier for the user to get the same shape as the one they defined in netlify.yml instead of a different one.

Finally this is easier to parse and manipulate when the netlify.yml is loaded programmatically (which users might do). It’s also easier to validate and do static analysis on.

[DavidWells]

Sounds good! I will submit a PR

Hold off on PRs on this for right now 😃. Need to figure out the shape

---

The object notation I described above works like this:

plugins:
  myLogicalPluginName:
    name: plugin-xyz
    foo: wowow
  myOtherLogicalName:
    name: plugin-xyz
    foo: coooooollllolololo

Here the plugin plugin-xyz is loaded twice with different params. The logical ids (aka parent keys) are different and therefore can be referenced individually like ${myLogicalPluginName.outputXyz} and ${myOtherLogicalName.outputXyz}

The name (or it could be type) field, is referencing the module name or the path to the import.

Local plugins are an important part of the story and I’m not to crazy about

plugins:
  myLogicalPluginName:
    name: ./my-local/plugin-xyz
    foo: wowow

On the other side, I think it is also confusing to have multiple keys name, import (orresolve)

Some design goals are:

• Keep it super simple to grok at first glance
• Flat as we can. You’re note on extra indentation is good one here
• Flexible enough to support advanced use cases. (using plugin multiple times, outputs, resolving a D.A.G., etc)

There are some advanced configuration techniques possible but I’m not certain we want to expose those just yet.

[DavidWells]

Thanks for the write up. I’m all for simplifying.

I think having 2 different words to load a plugin path and name might be confusing.

In any case, I’ve been thinking about the plugin shape for a while and plugins might need to be an object rather than an array.

plugins:
  pluginXyz:
     name: foo-bar
     optionOne: 'hi
  pluginZaz:
     name: otherThing
     optionOne: 'hi

There are a couple reasons for this:

• Support for inputs & outputs to plugins
• Building a DAG of the lifecycle and making sure things run in the correct order
• Allowing for plugins to be used multiple times with different inputs (and output value refs)

For example. Lets say a mongo-db plugin returns a connection string as an output. Then a second plugin mongo-db-crud-function relies on that connection_string value returned from the first plugin.

We need a way for values to be referenced from plugins in other plugins.

Example:

plugins:
  pluginXyz:
     name: mongo-db
     optionOne: hi
  pluginZaz:
     name: mongo-db-crud-function
     mongoURL: ${pluginXyz.connection_string}

It’s not really possible to reference values easily from a position in an array