Define a JS format for Sass plugins

[nex3]

Users want to load plugins when using Dart Sass and Node Sass via the command line (see sass/dart-sass#264). This means we need a way for such plugins to be defined in a way that makes sense for both Dart Sass and Node Sass. Plugins may include Sass stylesheets as well as functions or importers defined in JS.

Note that Eyeglass has a format that works here, so it may make sense to integrate with that somehow. However, this would mean that some aspects of the raw executables would only work in an Eyeglass context, which might be a problem.

[chriseppstein]

Eyeglass has a very simple integration point that I think can be a general contract for any such plugin system.

Given an single option -r PLUGIN to any js-capable executable.

The executable can integrate to any generic plugin, or plugin system like so:

// pseudo code inside the sass implementation
const parseOptions = require("someOptionParser");
let execOptions = parseOptions();
const plugin = execOptions['-r'] ? require(execOptions['-r']) : ((opts) => opts);
let sassOptions = {}; // calculates options from other arguments to executable
sassOptions = plugin(sassOptions);
// goes on to render the file(s) with these options.

// npm module: PLUGIN/index.js
module.exports = function(options) {
  // calculate new options or changes to them.
  return options;
}

If desired, this contract can be extended to support multiple invocations of the -r option where options are chained in order to them.

Eyeglass would trivially integrate with this system, and it would allow for other such frameworks.

[xzyfer]

I think what ever approach we take it's important to respect the existing conventions of the JavaScript tooling community. We should look at libraries like postcss, webpack, and parcel for example as inspiration.

…

On Sat., 28 Apr. 2018, 6:13 am Chris Eppstein, ***@***.***> wrote: Eyeglass has a very simple integration point that I think can be a general contract for any such plugin system. Given an single option -r PLUGIN to any js-capable executable. The executable can integrate to any generic plugin, or plugin system like so: const parseOptions = require("someOptionParser");let execOptions = parseOptions();const plugin = execOptions['-r'] ? require(execOptions['-r']) : ((opts) => opts);let sassOptions = {}; // calculates options from other arguments to executable sassOptions = plugin(sassOptions);// goes on to render the file(s) with these options. If desired, this contract can be extended to support multiple invocations of the -r option where options are chained in order to them. Eyeglass would trivially integrate with this system, and it would allow for other such frameworks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2511 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWC08Dohw1sClWDdh3VCqbUMhC-j-ks5ts3vlgaJpZM4Tpfup> .

[nex3]

@xzyfer Can you do a survey of what those libraries do?

[ArmorDarks]

Worth to mention JSPM and SystemJS (that's what JSPM uses under the hood) to the list.

SystemJS implements ES module specs — what some modern browsers already supporting — so it should be regarded as a more accurete source of truth.

[chriseppstein]

There are a couple of config loader systems that are used in the js world to read from standard location(s):

• https://github.com/dominictarr/rc
• https://github.com/davidtheclark/cosmiconfig

I'm sure there are others. This is more for app's than plugins. I would expect the config to be able to specify plugins that would then receive the resolved configuration from all possible sources (including the CLI options, if any)

[xzyfer]

The rc package is my initial thought also. I'm on vacation until mid June so I haven't looked any further into this.

…

On Mon., 21 May 2018, 11:50 pm Chris Eppstein, ***@***.***> wrote: There are a couple of config loader systems that are used in the js world to read from standard location(s): - https://github.com/dominictarr/rc - https://github.com/davidtheclark/cosmiconfig I'm sure there are others. This is more for app's than plugins. I would expect the config to be able to specify plugins that would then receive the resolved configuration from all possible sources (including the CLI options, if any) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2511 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWDHpiHOXVPe_PnBGtACHbiS1FwJnks5t0za7gaJpZM4Tpfup> .

[ArmorDarks]

Also worth to check how it's done in Babel, ESLint, Stylelint and Jest

[nex3]

I'm less interested here in how we define what code will be loaded, whether that's through a configuration file or command-line options or whatever, than I am in what that code will look like.

The Eyeglass method for defining plugins is to take some sort of configuration object as a parameter and return it modified however. This is a possibility, but I'm not sure there's a clear use-case for plugins manipulating configuration other than by defining functions and importers, and as a matter of policy I'd like to keep the surface area as small as possible to give us more flexibility both for future changes and in how individual implementations represent their configuration.

[chriseppstein]

Most of these examples have a way of extending a configuration from a known location. I’ve not seen one that has a notion of composing configuration from several locations that are independent of the others.

[lunelson]

This discussion has probably moved on already; but FWIW I would suggest that plugins may want to receive the sass instance (whether it be node-sass or dartsass) as well as a config object, I've found this to be helpful 🤷‍♂