Actionable warning for Your build is slower because some babel plugins are non-serializable?

[johanrd]

Hi. When building a fresh app with ember-test-selectors installed, I get the following warning:

[ConfigLoader]WARNING: Your build is slower because some babel plugins are non-serializable

I could have created an issue over at ember-test-selectors to see if this is easily fixable from there. However, I am not completely sure how useful this message itself would be for them.

Would it make sense to provide some actionable best-practices we could link to for ember-addons to be non-"non-serializable"?

[rwjblue]

Part of the issue is due to a misalignment between how broccoli-babel-transpiler handles the parallelization vs how ember-cli-htmlbars handles it. The parallelization system that exists within Embroider assumes the two systems are compatible, but unfortunately they are not (which is 100% my fault, but here we are... 😞 ).

The good news is that we are actively working on aligning the two systems, and fixing this issue for the majority of folks that see it only under Embroider builds. Unfortunately, I'm not sure exactly how long that will be (hopefully "soon", but still a bit TBD).

---

To alleviate the issue for your builds right now you can use pluginHints to help avoid the message:

embroider/packages/core/src/options.ts

Lines 60 to 71 in bdea400

	// This is a performance optimization that can help you avoid the "Your build
	// is slower because some babel plugins are non-serializable" penalty. If you
	// provide the locations of known non-serializable objects, we can discover
	// them and make them serializable.
	//
	// resolve is a list of paths to resolve, in a chain. This lets you resolve
	// your dependencies' dependencies, like: resolve: ['your-dependency',
	// 'inner-dependency/lib/transform']
	//
	// useMethod optionally lets you pick which property within the module to use.
	// If not provided, we use the module.exports itself.
	pluginHints?: { resolve: string[]; useMethod?: string }[];

[ef4]

One challenge here is that the reason a plugin is non-serializable is that we have no idea where it came from. So it's hard to tell in the error message who's responsible.

But you're right, we could at least include a URL in this message explaining more what it means and how to address it.

[ef4]

Specifically for ember-test-selectors, you can manually tell Embroider where to find its plugins like this:

return compatBuild(app, Webpack, {
    pluginHints: [
      {
        resolve: [
          'ember-test-selectors/transform-test-selector-params-to-hash-pairs',
        ],
      },
      {
        resolve: ['ember-test-selectors/strip-test-selectors'],
      },
    ],
  });

[alexlafroscia]

I'm running into something similar that's a bit confusing. Embroider is reporting this warning for the transformation from ember-element-helper, but the addon that it seems to be processing doesn't support on that dependency.

Here, ember-fetch seems to be the thing being processed when the warning is shown. The plugin that gets printed after that is the one for ember-element-helper

Would the "solve" here to do something like

{
  pluginHints: [
    {
      resolve: [
        'ember-fetch', 'ember-element-helper/lib/element-helper-syntax-plugin.js'
      ]
    }
  }
}

Even though ember-fetch shouldn't be triggering that transform?

Edit: I tried this and it didn't work... removing ember-fetch also didn't work. The ember-element plugin still mentions not being serializable.

[alexlafroscia]

One challenge here is that the reason a plugin is non-serializable is that we have no idea where it came from.

@ef4 is there something that addons could be doing to make it so that Embroider does know where the transforms are coming from? I'd love to make PRs against the plugins generating this warning to fix it on their end, if there's something they can do.

[ef4]

I'm running into something similar that's a bit confusing. Embroider is reporting this warning for the transformation from ember-element-helper, but the addon that it seems to be processing doesn't support on that dependency.

I think you're being mislead by the ordering of the output. I don't think there's any guarantee that you can tell which addon's broccoli tree caused the warning. If you know the problematic plugin is from ember-element-helper, use yarn why ember-element-helper or npm explain ember-element-helper to see how they're getting into your app.

[ef4]

is there something that addons could be doing to make it so that Embroider does know where the transforms are coming from?

The addons were already doing what ember-cli-htmlbars supports, but embroider didn't understand that. This should fix it: #754

[acorncom]

Should this issue be closed?