Skip to content

element OSS and 47->18 schematics #848

@spike-rabbit

Description

@spike-rabbit

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:

  1. ng update @simpl/element-ng (will also update all related packages like the theme)
  2. 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
  3. ... 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.

  1. It must be possible to run all schematics separately, so code changes are not that overwhelming per script
  2. Schematics itself are supposed to be rather simple, complex changes are a matter for humans and AI
  3. ng-add by default should only do a bare minimum
  4. 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:

  1. 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)?
  2. commit changes
  3. ng g @siemens/element-ng:migrate-v47-to-v48
  4. commit changes
  5. ng g @siemens/element-ng:migrate-ts-imports-to-siemens
  6. commit changes
  7. ng g @siemens/element-ng:migrate-scss-imports-to-siemens
  8. commit changes

The following migrations in general should be implemented:

ng-add

  1. Install dependencies: @siemens/{element-ng,element-theme,element-translate-ng}, @simpl/brand
  2. Install optional dependencies if respective @simpl packages are present: @siemens/{charts-ng,maps-ng,dashboards-ng}

v47-to-v48

  1. Rename components to legacy: si-icon, si-tabs, siPopover
  2. 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
  3. Rename changed APIs: SiCollapsiblePanelComponent.toggle --> panelToggle
  4. Adjust the wizard navigation buttons, set inlineNavigation or remove inlineNavigation="false" so that the behavior is not changed in the app
  5. Remove deprecated methods of action-modal :- SiActionDialogService.showAlertDialog, SiActionDialogService.showConfirmationDialog, SiActionDialogService.showEditDiscardDialog, SiActionDialogService.showDeleteConfirmationDialog.
  6. Remove AlertDialogResult, EditDiscardDialogResult, ConfirmationDialogResult and DeleteConfirmationDialogResult as const objects. Use them only as type

ts-imports-to-siemens

  1. 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

  1. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions