-
Notifications
You must be signed in to change notification settings - Fork 9
Description
Update
After a first attempt of building the ng-add
schematics we were running into dependency conflicts.
The second "challenge" is to actually figure out the versions of @simpl
packages and the corresponding @siemens
packages.
To solve this we could go a different way using ng update
. We initially decided against ng update
as our internal registry does not ship the required meta data. After some testing, it turned out, that this does not effect the packageGroup
field and one can run migration schematics manually. So we can basically build this flow from an application point of view:
ng update @simpl/element-ng
(will also update all related packages like the theme)ng update @simpl/element-ng --migrate-only --from 47 --to 48
(installs siemens dependencies and then run v47-to-v48 script of@siemens/element-ng
- ... as below
With this we no longer need to worry about versions. ng update
will install the correct @simpl/*
versions our script can read then from the peerDependency
field the required @siemens/element-ng
version.
The v47-to-v48
can still remain in @siemens/element-ng
since angular allows calling other external schematics.
This also no longer requires abusing ng-add
, instead we can follow the typical flow provided by angular.
In case our internal registry fixes the meta data issues, the second step from above would no longer be needed.
Original Issue
Since we are now starting to introduce schematics, we should actually have a plan here.
After discussion with @kfenner and @timowolf we agreed on the following approach on a higher level.
- It must be possible to run all schematics separately, so code changes are not that overwhelming per script
- Schematics itself are supposed to be rather simple, complex changes are a matter for humans and AI
- ng-add by default should only do a bare minimum
- we should not diverge from our recommended update strategy (first: add dependencies, second: v47 to v48 breaking changes, third: OSS package replacement)
For this migration we have two ways to run schematics: ng-add
and ng-generate
.
The recommended migration flow with scripts would roughly be like this:
- Run
ng add @siemens/element-ng@48
@kfenner / @timowolf should this step even allow to run the migration scripts afterwards automatically (so no commits possible in between)? - commit changes
ng g @siemens/element-ng:migrate-v47-to-v48
- commit changes
ng g @siemens/element-ng:migrate-ts-imports-to-siemens
- commit changes
ng g @siemens/element-ng:migrate-scss-imports-to-siemens
- commit changes
The following migrations in general should be implemented:
ng-add
- Install dependencies:
@siemens/{element-ng,element-theme,element-translate-ng}
,@simpl/brand
- Install optional dependencies if respective
@simpl
packages are present:@siemens/{charts-ng,maps-ng,dashboards-ng}
v47-to-v48
- Rename components to legacy:
si-icon
,si-tabs
,siPopover
- Remove unused deprecated APIs in client code:
SiAccordionComponent.colorVariant
,SiDateInputDirective.dateInputDebounceTime
,SiDateRangeComponent .debounceTime
,SiDatepickerDirective.triggeringInput
,SiFilteredSearchComponent.showIcon
,SiFilteredSearchComponent.noMatchingCriteriaText
,SiFormItemComponent.inputId
,SiFormItemComponent.readonly
,SiNavbarVerticalComponent.autoCollapseDelay
,SiSplitPartComponent.headerStatusColor
,SiSplitPartComponent.headerStatusIconClass
,SiTreeViewComponent.disableFilledIcons
,SiTreeViewComponent.trackByFunction
- Rename changed APIs:
SiCollapsiblePanelComponent.toggle --> panelToggle
- Adjust the wizard navigation buttons, set
inlineNavigation
or removeinlineNavigation="false"
so that the behavior is not changed in the app - Remove deprecated methods of action-modal :-
SiActionDialogService.showAlertDialog
,SiActionDialogService.showConfirmationDialog
,SiActionDialogService.showEditDiscardDialog
,SiActionDialogService.showDeleteConfirmationDialog
. - Remove
AlertDialogResult
,EditDiscardDialogResult
,ConfirmationDialogResult
andDeleteConfirmationDialogResult
as const objects. Use them only as type
ts-imports-to-siemens
- Rename all imports form
@simpl
to@siemens
where needed. May includes importing components from another entry point as the OSS repo no longer has the general entry-point feat(migration): add schematics for Siemens migration #815
scss-imports-to-siemens
- Rename all scss imports and adjust the main scss by the application to use the simpl/brand package. feat(schematics): migrate style imports to siemens #841