Open vlascik opened 1 year ago
Nothing deliberately changed in 3.x.
I wonder if you're getting some state leakage across separate builds. If you see this error, then rm -rf node_modules/.embroider
and then try again, does it go away?
I wonder if you're getting some state leakage across separate builds. If you see this error, then
rm -rf node_modules/.embroider
and then try again, does it go away?
Nope, the error stays the same regardless of whether that folder exists or not. From what I have seen in the debugger, this htmlbars ast transform/plugin gets marked as "global", whatever that means in embroider parlance, and then throws at node_modules\@embroider\core\src\portable.js:111
So we debugged this today in the triage meeting. It looks like there is something going on with the addon ember-bind-helper
in the way that it's registering it's ast transform
It looks like they are passing an object to registry.add()
https://github.com/Serabe/ember-bind-helper/blob/master/index.js#L7-L13
but that required object won't be serializable. I don't know how or why that's a requirement or even if something has changed in this regard recently 🤷 but I found just passing the plugin by name seems to work, even though the repro repo didn't have an example of using the ember-bind-helper
so I wasn't able to verify.
setupPreprocessorRegistry(type, registry) {
registry.add("htmlbars-ast-plugin", {
name: "bind",
plugin: "ember-bind-helper/lib/bind-transform"
});
}
Thank you! This fixed the problem in this case, but I suspect it will reappear with other addons later: according to EmberObserver codesearch, passing require
into ast transform's plugin
is fairly common (20 addons).
https://emberobserver.com/code-search?codeQuery=plugin%3A%20require
@mansona thanks, we should add this to the list of things to officially deprecate upstream. We aren't ever going to be able to fully support non-serializable plugins safely. It definitely won't work in vite.
Embroider also has a pluginHints option that lets you deal with an addon that is injecting non-serializable plugins. In this case, assuming ember-bind-helper
is a direct dependency of the app, it would be pluginHints: [ { resolve: ["ember-bind-helper/lib/bind-transform"] } ]
That still didn't explain why this changed from a warning to an error, because we used to detect whether the config was serializable (and thus safe to parallelized across processes) or not, and force everything to run single-process when it's not serializable. So I went looking and, well, oops:
I guess we need test coverage for this case.
passing require into ast transform's plugin is fairly common (20 addons).
Many of those are serializable though because they use an explicit API to become so. The first hit I saw on that list is our own @embroider/addon-shim
and its plugin uses parallelBabel
to make itself serializable:
The ability to pass a name instead of a function is relatively recent. I added it in babel-plugin-ember-template-compilation. For most of time, addons had to pass a function, but they could annotate it with parallelBabel
to make it serializable. So that is the most common case you'll find in the wild.
Since many large apps run with the ember-cli-babel setting throwUnlessParallelizable: true
for the performance benefits, a lot of the non-serializable cases in the ecosystem have been fixed. But of course not all of them.
I get the same error when trying my project with embroider
. I do have ember-box
(which has the same "problem" as ember-bind-helper
) but even if I apply the fix from above or even remove it from my package.json
- the error remains. How can I figure out what the problem is?
How can I figure out what the problem is?
Without embroider, add throwUnlessParallelizable: true
to your ember-cli-babel settings. It should print the source code of the unserializable function. You can search for that to see which addon it's coming from.
Thanks! I have 2:
1: name: unknown, location: unknown
2: name: unknown, location: unknown
:smile:
I have a slight idea that it might be ember-cli-styles but how do I find for sure?
I'm confused. Having the simplest Ember app - when one adds includeExternalHelpers
- it stops working with parallelization:
[Babel: Babel: foo] was configured to `throwUnlessParallelizable` and was unable to parallelize a plugin.
plugins:
1: name: unknown, location: unknown
Is that known and how does one workaround it?
I hit this tonight and realized in my case it was because objects with null prototypes are being treated as unserializable.
I had an object with a null prototype because I was using import * as Settings from './'
as a pattern. Settings
in this case gets a null prototype. Object.assign({}, Settings)
was enough to fix it.
After updating from embroider 2.x some addons with babel transforms started to break the build.
Were there any changes to those (couldn't find any documentation), or is it a bug?
Repro: