Assisted migration with CoPilot

[leagrdv]

Prompt model

Here is a prompt base I've done to migrate a simple sp-intranet-header to the new post-header.

Migrate the sp-intranet-header to the new post-header.
Here is the structure of the new <post-header>:

<post-header text-menu="Menu">
    ... Content of a default post-header ...
</post-header>

Based on that new structure, migrate the existing sp-intranet-header.

Guide for the migrations:

• Each <post-...> component needs to be imported from '@swisspost/design-system-components-angular'
  • In the case of a standalone Angular project, each component needs to be added in the imports: ... of the .ts file where the header is being used.
  • In the case of a non-standalone Angular project, each component needs to be added to the imports array of the module where the header is being used.
• When in an Angular project, the attributes need to be changed from kebab-case to camelCase (e.g. "text-menu" -> "textMenu").
• If the intranet header has "showIntranetSearch" set to true, show the search button that is present in the "local-nav" slot of the new header.
• If the intranet header has "logoUrl" set, use that as the url for the "post-logo" slot of the new header. If not, use "/".
• If the intranet header has "searchUrl" set, use that as the href for the search button in the "local-nav" slot of the new header. If not, use "#".
• If the intranet header has "siteTitle" set, use that as the text for the "title" slot of the new header. If not, use "Application title".
• All of the links within the sp-intranet-header (the ones with "nav-link") should be moved to the "main-nav" slot of the new header. If the links are at the top level of the sp-intranet-header, they should be added as top-level links in the "main-nav" slot. If the links are within a dropdown (the ones with "ngbDropdown"), they should be added as a megadropdown in the "main-nav" slot, with the title of the dropdown being the text of the megadropdown trigger and the links within the dropdown being added to the megadropdown itself. If "hasNavbar" is set to false, that means the application has no links. In that case, the post-mainnavigation component should not be added to the new header.
• The order of the links should stay the same.
• Once it has been verified that the new header is working correctly, the old sp-intranet-header should be removed from the project. The @swisspost/design-system-intranet-header package can also be removed from the dependencies if it is no longer being used anywhere else in the project.

Findings (and issues)

The intranet header is very customizable and can be used in many different ways, which makes it pretty much impossible to do a proper common migration for most use cases:

Example for Project 1 (SDSC)

  <sp-intranet-header
      [hasNavbar]="false"
      [siteTitle]="windowWidth > 800 ? 'Sorem Dpsum Sorem Cpsum' : 'SDSC'"
      [currentUserId]="(getUserDisplayName() | async) ?? ''"
      [optionDropdownContent]="optionDropdownContent"
      [optionHeaderContent]="optionHeaderContent"
  ></sp-intranet-header>

AI Migration

A few issues result of the common migration:

• There is no navbar, meaning no links to be changed into the new header (main navigation/megadropdown), which are the elements that can most easily be migrated with AI.
• Site title changes depending on the window's width -> It works with the AI migration but there might be some more complex things that user are doing with the sp-intranet-header that might not be caught and migrated correctly with the AI.
• The [optionDropdownContent] and [optionHeaderContent] are two props that can pretty much contain anything. Making a common migration for this is not possible.

Example for Project Escape Room

<header
	class="flex h-16 items-center justify-between border-b-2 border-gray-300 bg-white pr-6"
> ... Custom HTML content built with tailwind ...
</header>

AI migration

They've created a custom header that looks like the intranet header but is not. Not possible to migrate without making some custom migration guideline for this specific use case.

Example of Project SPV

  <sp-intranet-header siteTitle="Sorem Ppsum Vabcd" [showIntranetSearch]="false">
      <li class="nav-item"><a class="col-auto py-3 px-5 nav-link" href="/ui/home">Home</a></li>
      <li class="nav-item"><a class="col-auto py-3 px-5 nav-link" href="/ui/v/submit">Vabcd</a></li>
      <li class="nav-item"><a class="col-auto py-3 px-5 nav-link" href="https://wikit.post.ch/">About</a></li>
  </sp-intranet-header>

AI migration

This is a basic use of the intranet header that works with the common migration: A list of links to move to the main navigation, a site title to move to the title slot, etc.

Conclusion

Though we could have a prompt for CoPilot automigration for the intranet-header, a lot of edge cases make it difficult. It's either we keep it simple and only migrate the things we know (titles, presence of the search button, links) but then more complex projects will either have to fix the things that AI tried to change incorrectly or we specify in the prompt not to touch the optionDropdownContent and optionHeaderContent and tell the user to handle that themselves; or we go through many existing implementations of this component and make something that could work for more edge cases but that would IMO take too long.

I do feel that some other components might be better candidates for AI migration, especially some that are time consuming and repetitive. The intranet-header is used only once per project and is not going to take too long for users to migrate.

Possible candidates:

• The post-tabs simply needs to have renamed components and props.
• heading-level on post-accordion is now required -> AI could be used to identify which heading level would fit best based on where the accordion is placed in a page.
• .pi-* classes (icons) are still widely used and could be easily replaced with AI by a post-icon component
• Subnavigation component replaced by the post-tabs -> Should not have too many edge cases and can easily be done with AI

Also, I think because the rules that were done in the ESLint migrations are all pretty simple ones, the whole thing could possibly be switched to a CoPilot prompt (this would take some time to write them all and make iterations to make sure it works well). That would solve the looping issue we currently have and allow us to add more elements to it.

Maybe each element of the migration guide could have a small CoPilot prompt associated to it that would handle it and allow users to run them one after the other for better control.