define guidelines for external formatters and resolvers

[caridy]

• what will be the pattern for the names of external formatters and resolvers? something like es6-module-transpiler-formatter-amd seems very ugly.
• what will be the keywords to facilitate discoverability of output formats?

[eventualbuddha]

This is a good idea. I agree that package name is ugly, but it at least is clear. I'd love to hear a better suggestion. How does es6, modules, and module-formatter or module-resolver sound?

[caridy]

Ok, let see if someone has a better idea, for now, I have this: https://github.com/caridy/es6-module-transpiler-formatter-system. @ericf suggested es6-module-transpiler-system-formatter, which sounds better IMO.

Another question on the same lines: I ended up duplicating lib/replacement.js into the formatter repo to avoid depending on es6-module-transpiler. Few weeks ago I mentioned this issue, and I proposed to have more abstraction in the pieces that are purely recast driven, so the transformation of the code can be done even outside of the realm of the es6-module-transpiler.

[domenic]

With peer dependencies you could depend on es6-module-transpiler without issues.

[stefanpenner]

@domenic i thought i heard rumors about peerDeeps maybe not sticking around

[domenic]

Nah, that'd break too many things.

[stefanpenner]

aren't they breaking things already?

[caridy]

@domenic no, I'm not doing that :), we have very bad experience with peerDependencies and shrinkwrap (e.g.: npm/npm#5135), you can get into a mess really fast with the peer dependencies when things move along in separate tracks. Aside from that, many people will have the transpiler installed as global (to use the cli), then the formatters installed locally, or simply have another tool, like broccoli-es6-module-transpiler depending on es6-module-transpiler, which will be messy.

[domenic]

The transpiler should not be installed globally :(

[caridy]

@domenic https://github.com/square/es6-module-transpiler#installation, I understand that most people will use a task wrapper instead of using es6-module-transpiler directly, and that's probably what we want to promote. But unfortunately there are a bunch of people in the industry using a dedicated VM to run the build process, in which case having the basic build tools as global speed up the process of doing npm install; npm test, we can denied that, as we can't denied that people do crazy stuff when they have a cli tool available, and peerDependencies are not going to work in all those cases.

I'm more interested in the other side of the coin here: are the basic transformations, and abstraction pieces of the transpiler useful to others in a form of a library that only depends on recast?