Babel accepts plugins as (among other things) either a string denoting a module to require, or a tuple containing that string and optionally some configuration for that plugin. It will also accept a singleton array with just the module path as a sort of degenerate version of the second case, i.e.
plugins: [
'/path/to/some/plugin.js',
['/path/to/some/plugin.js', { config: true }],
['/path/to/some/plugin.js']
]For the third entry, the parallelization logic interprets that plugin as ['/path/to/some/plugin.js', undefined], and since undefined isn't JSON-serializable, the plugin is considered unparallelizable. That's easy enough to work around, but the error message we got with throwUnlessParallelizable turned on looked like:
[broccoli-persistent-filter:Babel > [Babel: ember-data]: Babel: ember-data] was configured to `throwUnlessParallelizable` and was unable to parallelize a plugin.
plugins:
1: name: unknown, location: unknown
If the relevant plugin path had been included in that output, it would have helped with tracking down the source of the problem.
Babel accepts plugins as (among other things) either a string denoting a module to require, or a tuple containing that string and optionally some configuration for that plugin. It will also accept a singleton array with just the module path as a sort of degenerate version of the second case, i.e.
For the third entry, the parallelization logic interprets that plugin as
['/path/to/some/plugin.js', undefined], and sinceundefinedisn't JSON-serializable, the plugin is considered unparallelizable. That's easy enough to work around, but the error message we got withthrowUnlessParallelizableturned on looked like:If the relevant plugin path had been included in that output, it would have helped with tracking down the source of the problem.