Plugins

[lencioni]

We have a list of environments that import-js can support out of the box. https://github.com/Galooshi/import-js#environments

Some of these have some pretty deep integrations, which is great. However, it seems like there could be an unlimited number of environments that we might want import-js to support, so I wonder if this is the best approach.

What if we made it so folks could write plugins for import-js? I think this would simplify the import-js codebase by moving environment-specific code to a plugin (e.g. move the meteor stuff into a plugin cc @rhettlivingston), and enable people to create new plugins that more specifically fit their needs (e.g. Ember #483) without import-js core maintainers being a bottleneck. This would also enable organizations with special internal requirements to create their own internal plugins and have more power over how import-js works.

Here are some open questions:

• How should plugins be consumed and wired up?
• Naming scheme?
• What hooks are required to support current functionality?
• What other hooks might we want immediately?

[trotzig]

How about

How should plugins be consumed and wired up?

I would advocate for using regular requires and injecting modules directly in .importjs.js. Something like

// .importjs.js
const nodePlugin = require('import-js-plugin-node');
const airbnbPlugin = require('./import-js-plugins/airbnb');

module.exports = {
  plugins: [nodePlugin, airbnbPlugin],
};

Naming scheme?

import-js-plugin-foobar?

What hooks are required to support current functionality? What other hooks might we want immediately?

I think the only way we can figure this out is through writing a plugin or two. Once we have a real use-case, it will be a interactive exploration, going back and forth between the plugin and import-js core.

[lencioni]

When exploring this, it might be worth thinking about how we might support things like Flow and TypeScript via plugins and whether or not that is worth doing with plugins or just baking it in directly as it is now.

[monovertex]

Is there any progress on this? I'd be interested in writing a plugin for Ember.

I would advocate for using regular requires and injecting modules directly in .importjs.js. Something like

Unless I misunderstood this, I think it will be pretty limiting to have plugins this way, since the import-js source will need to be updated when new plugins appear. Maybe taking a look at how eslint does plugins would be a good idea?

[mikabytes]

I'm interested in working on this.

Here's a list of issues that would benefit from plugin support (I'll update as I find more): #555 #533 #556 #564 #522 #550 #520 #519 #483

I think adding plugins with regular require in the configuration file is the way to go, as trotzig mentioned above. As for the interface, the best way is probably to just write a few plugins to figure out what the requirements and constraints are.

We already support a bunch of stuff in the core that could be extracted into plugins. Environments, meteor, etc.