From a7eb25f40f175dc0c2776ed19ed96b76f6174f9f Mon Sep 17 00:00:00 2001
From: Jenny Schweers
- We are taking an app-by-app approach to migrating from Bootstrap 3 to 5. This process is summarized by the following:
+ Bootstrap is a third-party UI library used throughout
+ HQ. It's essentially a set of stylesheets and javascript widgets. This means that migrating from one version to the
+ next involves the following kinds of work:
+
+
update this notice and leave this page as documentation for the next Bootstrap migration.
+
+ dropdown-item
class.
+ Our migration tool detects widgets that need to be updated, although a developer is needed to implement
+ the changes. The tool can automatically make other HTML-related changes, such as renaming attributes
+ like data-toggle
that have been renamed in the new version.
+
+ Because the HQ codebase is large, we are taking an incremental approach to this migration. + For organizational purposes, we are executing and tracking this migration primarily on an app-by-app basis. +
+
+ Multiple versions of Bootstrap cannot coexist on the same page.
+ The @use_bootstrap5
decorator marks individual views as migrated to Bootstrap 5. This decorator
+ sets a use_bootstrap5
attribute on the request that's used to set up the
+ relevant Bootstrap environment.
+
+ This means that files that are required by both migrated and unmigrated pages need to be "split" into two
+ versions: one to include on Bootstrap 3 pages and another to include on Bootstrap 5 pages. This applies largely to code that
+ is fundamental to HQ's UI and used throughout the platform, such as the hqwebapp
app, the
+ analytics JavaScript libraries, etc.
+
+ It can also be helpful to "split" files in this way while migrating an app. This allows + Bootstrap 5 changes to be developed, reviewed, and merged in small pieces, before switching the Bootstrap + version used in production. It is a more complex process that adds more code during the migration, + although most of this code is automatically generated by the migration tool. + In these cases, once the app is fully migrated, the Bootstrap 3 files can be deleted. +
++ To support this approach, we have tooling that facilitates "splitting" and "unsplitting" files: + copying files, moving them, and updating references to them. This tooling also performs the simpler migration + updates, such as renaming CSS classes. For updates that it cannot handle automatically, it adds a TODO comment + to the relevant code and writes out a changelog. +
+
+ Once the entire platform is fully migrated to Bootstrap 5, any remaining Bootstrap 3 code can be removed:
+ the Bootstrap 3 versions of files in hqwebapp
and similar apps, the @use_bootstrap5
+ decorator, any code related to request.use_bootstrap5
or window.USE_BOOTSTRAP_5
,
+ the Bootstrap 3 stylesheets and JavaScript library, and so forth.
- Using an automated process, split template and javascript files that need changes into bootstrap3
- and bootstrap5
versions. This process will find/replace the straightforward changes and flag
- more complex changes to be addressed later.
-
- Migrate views in the app one-by-one by applying the @use_bootstrap5
decorator and
- ensuring template and javascript files for that view inherit from bootstrap5
base templates
- and javascript dependencies. This process will be visual in nature, and may involve updates to the
- Bootstrap 5 stylesheet and/or restructuring HTML and javascript components to ensure the view renders properly
- with no javascript errors.
-
- Once bootstrap3
versions of a template or javascript file are no longer referenced, the
- bootstrap5
version can be "un-split" and the file moved back to the original location prior to
- the split.
-
- An app will be considered fully migrated when all template and javascript files are no longer split into
- bootstrap3
and bootstrap5
versions and every view in the app is decorated with
- @use_bootstrap5
.
-
- Once all apps are fully migrated to Bootstrap 5, we can then remove the use of the any in-template splits
- referencing request.use_boostrap5
, so that any Bootstrap 3 related code is removed. Lastly, a final
- cleanup should be done to remove the @use_bootstrap5
decorator from all the views.
-
- Before you begin the migration of an app, please announce your intention to do so in #gtd-dev
. It is
- important to communicate timelines for how long you expect the "split files" stage to last. Additionally, please
- ask that people refrain from any front-end development in that app until changes from the split files step have
- been merged.
-
+ The migration tool supports two general workflows for migrating an app: one based on splitting all files into + Bootstrap 3 and Bootstrap 5 versions, and one based on migrating files "in place." The splitting files approach + is necessary for apps that are dependencies for other apps, which will need to support both + Bootstrap 3 and Bootstrap 5 for a while. It is optional for small, independent apps. +
+
+ Before you begin the migration of an app, please announce your intention to do so in #gtd-dev
.
+ It is helpful to be aware of other front-end development in the app. If the app has ongoing front-end
+ development, consider delaying either that development or the migration, to reduce code conflicts.
+ After announcing your intent to migrate the app, please update
+ the app's migration status.
+
+ For small apps that are not depended on by other apps, the migration tool supports a streamlined process that + does not require splitting files into a Bootstrap 3 and Bootstrap 5 version. This is a good option for apps + with a small number of views, as it involves fewer pull requests and avoids the overhead of splitting files. + This approach does the entire migration in a single pull request, which + makes it unlikely to be a good choice for apps with 10+ views. +
++ To begin a "no split" migration, first + lint the app's JavaScript + and make a pull request for any linting changes. Then, to begin the actual migration, run: +
+./manage.py migrate_app_to_bootstrap5 <app_name> --no-split+
+ This will iterate through all the templates and javascript files in <app_name>
,
+ applying all automated fixes and adding TODO comments for fixes that aren't automated. After
+ staging the changes to each file, you will have the option to auto-commit those changes.
+
+ For each migrated template, the command will wait for you to apply the @use_bootstrap5
decorator
+ to the relevant views (see Migrating Views) before moving on to the next template.
+
+ Once all the files are migrated in-place, go through the TODO comments, which reference helper documents in the + changes_guide directory. +
++ After all TODOs are addressed, test your work: load the page and + test out any interactivity. Most migrations should also go through QA. Migrations can skip QA if they make + relatively superficial changes and are in low-risk areas. +
++ Also mark the migration as "complete" as part of your pull request. This updates a status file where we + programmatically track the status of the overall platform migration. To do so: +
+./manage.py complete_bootstrap5_migration <app_name>+
+ You're done! Ignore the rest of this document. +
+
The next step is to split affected template and javascript files into bootstrap3
and
@@ -336,36 +388,6 @@
build_bootstrap5_diffs
to rebuild the diffs.
-
- Some apps only have a handful of templates and javascript files, and it's possible to run the auto-migration
- on the templates in-place and migrate the views to Bootstrap 5 all within the same Pull Request. In this case,
- you can make use of the --no-split
option for migrate_app_to_bootstrap5
.
-
./manage.py migrate_app_to_bootstrap5 <app_name> --no-split-
- This option will iterate through all the templates and javascript files in <app_name>
. After
- staging the changes to each file, you will have the option to auto-commit those changes.
-
- For each migrated template, the command will wait for you to apply the @use_bootstrap5
decorator
- to the relevant views (see Migrating Views) before moving on to the next template.
-
- Once all the files are migrated in-place, you can then make additional manual changes to each template and view. - When the views are fully migrated, you can then create your pull request. -
-- This option is useful for smaller apps, because it avoids the split-files and reference renames. Please only - choose this option if you are confident you can migrate all the views and javascript files within 1 to 2 weeks. -
-