refactor: rename experimentalDynamicComponents to dynamicImportConfig #3563
Conversation
| @@ -45,7 +45,7 @@ const { code } = babel.transformSync(source, { | |||
| - `name` (type: `string`, optional) - name of the component, e.g. `foo` in `x/foo`. | |||
| - `namespace` (type: `string`, optional) - namepace of the component, e.g. `x` in `x/foo`. | |||
| - `isExplicitImport` (type: `boolean`, optional) - true if this is an explicit import. | |||
| - `dynamicImports` (type: `object`, optional) - see below: | |||
| - `dynamicImportConfig` (type: `object`, optional) - see below: | |||
| - `loader` (type: `string`, optional) - loader to use at runtime. | |||
| - `strictSpecifier` (type: `boolean`, optional) - true if a strict specifier should be used. | |||
There was a problem hiding this comment.
While we are at this, do we still need the strictSpecifier option?
There was a problem hiding this comment.
Good idea! I'll check to see if we're actually using the strictSpecifier anywhere and remove it if we don't need it.
It might help reduce the coordination effort and @nolanlawson also suggested keeping the I think depending on who is actually using the option it may be necessary, although AFAIK it's just |
|
/nucleus test |
Details
Now that dynamic components are going GA, this PR renames the
experimentalDynamicComponentscompiler option todynamicImportConfig.The new name is to be more in line with the function of the compiler option (to provide configuration options for dynamic imports).
This PR will require coordinating a release with downstream projects that need the compiler options updated (W-13519768).
Does this pull request introduce a breaking change?
Downstream teams that use the
experimentalDynamicComponentscompiler options will need to switch todynamicImportConfig.Does this pull request introduce an observable change?
The
experiementalDynamicComponentsoption will no longer be a valid compiler option.GUS work item
W-12607866