-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: rename experimentalDynamicComponents to dynamicImportConfig #3563
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are at this, do we still need the strictSpecifier
option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! I'll check to see if we're actually using the strictSpecifier
anywhere and remove it if we don't need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to eliminate the overhead of a coordinated release by temporarily introducing dynamicImportConfig
alongside experimentalDynamicComponent
and removing the latter at a later time?
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
experimentalDynamicComponents
compiler 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
experimentalDynamicComponents
compiler options will need to switch todynamicImportConfig
.Does this pull request introduce an observable change?
The
experiementalDynamicComponents
option will no longer be a valid compiler option.GUS work item
W-12607866