by Jake Champion.
Tagged with Newsletter.
We are migrating Origami Components from Bower onto the npmjs registry, this will be done by the end of Q2. Once the Origami Components are on npm, the versions on Bower will go into a deprecated state where they have no new features added. Products/Projects which want to get new Origami designs and features will need to migrate to npm.
We are also deprecating the Bower Registry, it will be placed into a maintenance only mode for 12 months and then we will look to decommission the service completely.
We recommend that all products/projects which use Bower migrate over to using the npmjs registry.
Yes, the team has done several migrations of our services and components in the past and know that helping our users migrate is very important.
We will be providing migration guides for every individual Origami component, as we have done in the past.
We will also provide written guidance on how to migrate a project from Origami via Bower to Origami via npmjs.
We are contactable via the Slack channel #origami-support if you want to speak to the team.
For teams which have too much to migrate on their own, we may be able to help migrate your products for you. If you would like our help migrating your products, please let us know in advance as there are only 3 of us, we won't be able to help every team.
1st July 2021 - Origami Components moved from Bower to npm and guides to migrate are written
1st July 2021 - Deprecate the FT Bower Registry
1st July 2022 - Decommission the FT Bower Registry
This affects every product/project which uses the FT Bower Registry. We've done a search across the entire Financial-Times GitHub account and collated all the projects which are affected and will need to migrate to an alternative Bower registry or off Bower completely. This google spreadsheet contains all the systems which are affected.
No you do not. If you are using any Origami Components via the Bower Registry then you will need to wait until we have migrated those Origami Components to the npmjs registry, which should be complete by the end of Q2. We will have guides on how to migrate from Bower to npm.
The time/effort varies drastically across products.
We know this will be a very big effort for Customer Products because they have many things on Bower themselves as well as having abstractions on top of Origami which will need to be migrated before they can migrate their products.
For Internal Products the effort should be smaller than Customer Products because they don't have extra abstractions to migrate first before migrating their products.
For FT Professional the effort should be the same as Internal Products.
Below is a breakdown of how many systems and repositories will need to be migrated, split by group:
|Group||Systems to migrate||Repositories to migrate|
|Operations & Reliability||3||41|
We can detect when the relevant repos have been updated to remove Bower. Using that data, once a week we will update:
The front-end community at large has already moved away from using Bower for their projects and has moved to using npm. This change can also be seen within the FT, as some individual teams have already moved onto npm. Due to fewer projects using Bower, the amount of infrastructure and tooling which exists that supports Bower has been decreasing or not been kept up-to-date with the advancements in the rest of the front-end industry. Origami has had to invest lots of time and energy into creating new tools and infrastructure to support Bower.
The Origami project was stuck using Bower due to other software registries not having the features that Origami required. This is no longer the case with the latest release of npm. With the Origami project migrating off Bower and onto npm, it enables us to deprecate the Bower Registry and accompanying infrastructure and tooling which has become a large piece of technical debt we have.