simplify plugin registration about faucet-pipeline-core

[moonglum]

I was way too tired.

[moonglum]

I don't understand where we get the bucket from?

[FND]

plugins should (optionally) determine bucket […] themselves

It seems highly unlikely that the choice of bucket might reasonably be user- or project-specific.

[moonglum]

I agree. But does the plugin expose its bucket type?

[FND]

I don't know what that means, exactly.

[moonglum]

Ok, again: Currently, we store the info of "which pipeline is in which bucket" here: https://github.com/faucet-pipeline/faucet-pipeline-core/blob/master/lib/index.js#L9-L25

Where will we store it in the future? Gimme some code.

[FND]

Right now, a plugin looks like this:

module.exports = (config, assetManager, { browsers, compact, sourcemaps } = {}) => {
    …
    return filepaths => Promise.all(…);
};

They might also export an object which includes their preferred bucket:

exports.bucket = "scripts";
exports.plugin = (…) => …;

[moonglum]

Ok, makes sense. Let's do this 👍

[FND]

For backwards compatibility (that is, so plugins work with faucet-core v1.x as well as v2.0), we might instead attach the bucket property to the function - that's a bit awkward though, so perhaps not worth worrying about?

[moonglum]

No. We have control over all plug ins, and by publishing this as 2.0 we mark it as a breaking change.

[FND]

Just playing devil's advocate here: What if someone updates faucet-sass to v2.0 but, for whatever reason, faucet-static stays at v1.0 (cf. faucet-js instructions)?

[moonglum]

Shouldn't this be a version conflict, because faucet-static expects a version < 2.0?

[FND]

AIUI npm would create node_modules/faucet-pipeline-static/node_modules/faucet-pipeline-core alongside node_modules/faucet-pipeline-core - which doesn't work for faucet though because there's a single (i.e. shared) entry point with node_modules/.bin/faucet.

[moonglum]

As discussed, we will try to make this a non-breaking change

[FND]

Actually, the proposal above just addresses plugin and bucket, not the configuration key though.

    js: {
        plugin: "faucet-pipeline-js",
        bucket: "scripts"    
    }

Thus in order to activate a custom plugin, users' configuration would look like this:

    foo: …,
    plugins: {
        foo: "faucet-pipeline-foo"
    }

This might be further simplified:

    foo: …,
    plugins: ["faucet-pipeline-foo"]

(Of course users would have to know which configuration key is used by the respective plugin and plugins might clash, but neither seems like an actual problem.)

[moonglum]

Yes, you are right. But I don't understand

    foo: …,
    plugins: ["faucet-pipeline-foo"]

Is this "convention over configuration", and we require faucet-pipeline-(\w+)?

[FND]

I'm a little offended that you'd think I'd propose something like that...

The respective plugin would determine all of the three aforementioned aspects:

exports.key = "js";
exports.bucket = "scripts";
exports.plugin = (…) => …;

[moonglum]

Mission accomplished ✅

Ok, understood. But then let's make it only an array, ok? More options are not a good idea I think. The rules would be:

• core requires everything that is in the plugins array (those can be package names or relative paths – just as require expects it), expecting that it exports key, bucket and plugin. It throws an error, if that is not the case.
• It then checks for all keys of the imported plugins as well as the default plugins (js, css, static, sass).

Right? So this would work:

  js: { ... },
  foo: { ... },
  bar: { ... },
  plugins: ["faucet-pipeline-foo", "../faucet-pipeline-bar"]

This is then only a breaking change for users of "unofficial plugins". As the only one I know of is faucet-pipeline-nunjucks which is not even published right now, I would not mark this as a breaking change.

[FND]

shia.gif

[moonglum]

👍
I'll do it on the train ride back on Thursday iff I'm not too tired.