[Experimental] Support template co-location and Embroider

[dfreeman]

This will (in theory) address #140 and #151. The goal is for this to be a non-breaking change, and the current plan is to release this as [email protected] to give folks a chance to test and offer feedback.

At a minimum, much better test coverage will be needed before this is declared stable, but Embroider doesn't yet support template colocation, and even if it did there are still a number of other configurations we need to maintain support for.

The testing setup in this repo is already about stretched to the limit in terms of the number of variations it's intending to cover, so a prerequisite for getting this tested will be moving to a test-packages style setup with multiple test apps and addons rather than the single dummy one. Additional beta releases may follow as that gets set up and bugs or incompatibilities are discovered.

[buschtoens]

This is potentially a breaking change.

We have an addon like this:

module.exports = {
  name: require('./package').name,

  createCssModulesPlugin(parent) {
    return new BreakpointsPlugin(parent, {
      breakpoints: this.breakpoints
    });
  },

  included() {
    this.breakpoints = require('./breakpoints.json');
  }
}

Prior to this change, included was called before createCssModulesPlugin. Now the order is changed.

For this simple case, the fix is easy:

module.exports = {
  name: require('./package').name,

  createCssModulesPlugin(parent) {
    return new BreakpointsPlugin(parent, {
      breakpoints: this.breakpoints
    });
  },

  init(...args) {
    this._super(...args);
    this.breakpoints = require('./breakpoints.json');
  }
}

[dfreeman]

☹️ My goal was for this overall release to be non-breaking, but I don't see a way around this timing change, because we now need access to the ECM options before we can set up the HTMLBars plugin. Technically we never made any promises about invocation order, but hiding behind that rules-lawyering feels pretty bad.

On the public registry, at least, I think you and I are the only two authors of packages with the ember-css-modules-plugin keyword, though of course there's no way to know about private packages. Do you have any sense of how much this is likely to impact the plugins you've written? I don't think any of mine (internal or public) are relying on it, but they're mostly fairly simple.

[buschtoens]

Personally and speaking for @ClarkSource I'm totally fine with this change. None of my public plugins break, and of all private ones this was the only one. 🎉

[dfreeman]

👍 Ok, we'll see if anyone else runs into this during the beta, and assuming they don't we'll plan to keep this in as a non-major change under the banner of "undefined behavior can't break"

[NullVoxPopuli]

is app/components/my-component/index.css also supported?