search

ember-cli / ember-cli-htmlbars

MIT License
77 stars 66 forks source link

inline-precompile transform breaks parallel builds #752

Closed runspired closed 2 years ago

runspired commented 2 years ago

I'm not actually sure it's the inline-precompile, it may be the regular precompile transform is misnaming itself:

image

This is using latest release (6.1.0) with 1.0.2 of babel-plugin-ember-template-compilation. However, this bug also manifests in the 5.x series albeit with a different source for the plugin.

runspired commented 2 years ago

This appears to be due to this line: https://github.com/ember-cli/ember-cli-htmlbars/blob/2f2cac93a5cb52eda4943d7a4a76cf25ae254029/lib/utils.js#L251

precompile is a non-serializable function. For a htmlbars transform the best option here is to pass in serializable options with the buildPlugin path in the (oddly named) parallelBabel hash.

Example:

addon-main.js

module.exports = {
  setupPreprocessorRegistry(type, registry) {
      if (type !== 'parent') {
      return;
      }
      const options = this.getOptions();
      const plugin = this._buildPlugin(options);

    plugin.parallelBabel = {
      requireFile: __filename,
      buildUsing: '_buildPlugin',
      params: options,
    };
    registry.add('htmlbars-ast-plugin', plugin);
  },
  _buildPlugin(options) {
    return {
      name: 'plugin-name',
      ext: 'hbs',
      plugin: require('./plugin/path')(options),
      baseDir: () => { return __dirname; },
    }
  }
}
runspired commented 2 years ago

I've been digging into why this doesn't fail the tests, and after making sure various dependencies matched our app (mostly latest) I still can't reproduce; however, I do notice that in our app these are added as babel plugins, whereas in the test suite these are not added as babel plugins and are ergo not undergoing the is-serializable check.

I think the test-suite is at fault here in some way, it seems to bypass the usual "ember addon" setup.

runspired commented 2 years ago

This was in part due to https://github.com/DockYard/ember-maybe-in-element/issues/52

ember-cli-htmlbars does not give a meaningful error when this occurs, and the error that is recorded is set to "debug" level which is even lower than log level and thereby doesn't show up when you use DEBUG=ember-cli-htmlbars:* by default.

This was also due to @embroider/macros plugins brought in by ember-validators. Of note, that add-on does not add any ast plugins of it's own, but it added embroider support and for the version we used it lists "@embroider/macros": "^0.41.0",. Likely it fell victim to this issue: https://github.com/embroider-build/embroider/issues/727

I think the actionable item here is to at a minimum surface the issue at the logger.error level instead of logger.debug level

Note there was a lot of misdirection here, because you're looking for why a babel plugin isn't parallelizable, but the htmlbars plugin determination for this occurs long before while deciding if it's (non babel) transforms are also parallelizable. Figuring out why the htmlbars plugin generated the non-parallelizable version is the tricky bit.