fix #7341 chore(project): move legacy-ui to legacy app (#7348)

Because

* legacy-ui is only used in legacy

This commit

* Moves legacy-ui to legacy

Co-authored-by: yashika-khurana <104033388+yashika-khurana@users.noreply.github.com>

.gitignore

@@ -81,7 +81,7 @@ target/
 
 # Hosted assets
 app/experimenter/served/
-app/experimenter/legacy-ui/assets/
+app/experimenter/legacy/legacy-ui/assets/
 app/experimenter/reporting/reporting-ui/assets/
 
 # Key files

Makefile

@@ -106,9 +106,9 @@ volumes_rm:
 
 static_rm:
 	rm -Rf app/node_modules
-	rm -Rf app/experimenter/legacy-ui/core/node_modules/
+	rm -Rf app/experimenter/legacy/legacy-ui/core/node_modules/
 	rm -Rf app/experimenter/nimbus-ui/node_modules/
-	rm -Rf app/experimenter/legacy-ui/assets/
+	rm -Rf app/experimenter/legacy/legacy-ui/assets/
 	rm -Rf app/experimenter/nimbus-ui/build/
 
 kill: compose_stop compose_rm volumes_rm

README.md

@@ -38,7 +38,7 @@ Check out the [🌩 **Nimbus Documentation Hub**](https://experimenter.info) or
 
     On all platforms:
     - Install [Node](https://nodejs.org/en/download/releases/) to match [current version](https://github.com/mozilla/experimenter/blob/main/app/Dockerfile#L29)
-     
+
     On Linux:
     - Install [Docker](https://www.docker.com/)
     - Install [yarn](https://classic.yarnpkg.com/lang/en/docs/install)
@@ -52,7 +52,7 @@ Check out the [🌩 **Nimbus Documentation Hub**](https://experimenter.info) or
         - Swap: Max 4gb
         - Disk: 100gb+
     - Install [yarn](https://github.com/yarnpkg)
-            
+
 1. Clone the repo
 
         git clone <your fork>
@@ -177,10 +177,10 @@ git config blame.ignoreRevsFile .git-blame-ignore-revs
    - Add `/experimenter/` and `/experimenter/app` folders to your workspace (File -> Add Folder to Workspace -> `path/to/experimenter/app`)
    - From the `/experimenter/app` folder, run `yarn install`
        - Make sure you are using the correct version of node
-          
+
            node -v
 
-       - Troubleshooting: 
+       - Troubleshooting:
            - [Changing node version](https://stackoverflow.com/a/50817276/12178648)
            - Clear npm cache: `npm cache clean --force`
 
@@ -450,10 +450,10 @@ For more detailed information on the Remote Settings integration please see the
 
 Experimenter has two front-end UIs:
 
-- [`core`](./app/experimenter/legacy-ui/core) is the legacy UI used for Experimenter intake which will remain until `nimbus-ui` supersedes it
+- [`core`](./app/experimenter/legacy/legacy-ui/core) is the legacy UI used for Experimenter intake which will remain until `nimbus-ui` supersedes it
 - [`nimbus-ui`](./app/experimenter/nimbus-ui) is the Nimbus Console UI for Experimenter that is actively being developed
 
-Learn more about the organization of these UIs [here](./app/experimenter/legacy-ui/README.md).
+Learn more about the organization of these UIs [here](./app/experimenter/legacy/legacy-ui/README.md).
 
 **Also see the [nimbus-ui README](https://github.com/mozilla/experimenter/tree/main/app/experimenter/nimbus-ui) for relevent Nimbus documentation.**
 

app/.dockerignore

@@ -11,7 +11,7 @@
 **/node_modules
 **/yarn-error.log
 docs
-experimenter/legacy-ui/assets
+experimenter/legacy/legacy-ui/assets
 experimenter/nimbus-ui/build
 experimenter/reporting/reporting-ui/assets/
 experimenter/served/

app/Dockerfile

@@ -58,7 +58,7 @@ RUN poetry check
 # Node packages
 COPY --from=file-loader /app/package.json /app/package.json
 COPY --from=file-loader /app/yarn.lock /app/yarn.lock
-COPY --from=file-loader /app/experimenter/legacy-ui/core/package.json /app/experimenter/legacy-ui/core/package.json
+COPY --from=file-loader /app/experimenter/legacy/legacy-ui/core/package.json /app/experimenter/legacy/legacy-ui/core/package.json
 RUN yarn install --frozen-lockfile
 
 COPY --from=file-loader /app/experimenter/nimbus-ui/package.json /app/experimenter/nimbus-ui/package.json
@@ -76,7 +76,7 @@ FROM dev AS ui
 
 
 # Build assets
-COPY --from=file-loader /app/experimenter/legacy-ui/ /app/experimenter/legacy-ui/
+COPY --from=file-loader /app/experimenter/legacy/legacy-ui/ /app/experimenter/legacy/legacy-ui/
 RUN yarn workspace @experimenter/core build
 COPY --from=file-loader /app/experimenter/nimbus-ui/ /app/experimenter/nimbus-ui/
 RUN yarn workspace @experimenter/nimbus-ui build
@@ -106,5 +106,5 @@ COPY --from=dev /usr/local/lib/python3.9/site-packages/ /usr/local/lib/python3.9
 COPY --from=dev /app/bin/ /app/bin/
 COPY --from=file-loader /app/manage.py /app/manage.py
 COPY --from=file-loader /app/experimenter/ /app/experimenter/
-COPY --from=ui /app/experimenter/legacy-ui/assets/ /app/experimenter/legacy-ui/assets/
+COPY --from=ui /app/experimenter/legacy/legacy-ui/assets/ /app/experimenter/legacy/legacy-ui/assets/
 COPY --from=ui /app/experimenter/nimbus-ui/build/ /app/experimenter/nimbus-ui/build/

app/experimenter/docs/adrs/0002-nimbus-front-end-directory-tree-and-stack.md

@@ -1,8 +1,8 @@
 # Nimbus Front-End: Directory Tree Changes and Use React/CRA, Bootstrap, and GQL
 
-* Status: accepted
-* Deciders: Lauren Zugai, Jody Heavener, Kate Hudson, Jared Lockhart
-* Date: 2020-09-09
+- Status: accepted
+- Deciders: Lauren Zugai, Jody Heavener, Kate Hudson, Jared Lockhart
+- Date: 2020-09-09
 
 ## Context and Problem Statement
 
@@ -15,63 +15,66 @@ This ADR, while slightly atypical as it does not serve to document a single arch
 ## Decision Drivers
 
 Drivers for directory tree changes:
-* A more obvious separation of concerns for:
-  * the front-end and back-end
-  * legacy front-end code and Nimbus front-end code
+
+- A more obvious separation of concerns for:
+  - the front-end and back-end
+  - legacy front-end code and Nimbus front-end code
 
 Drivers for the proposed new stack:
-* Development speed
-* Better development tooling which is especially important since we intend to move a lot of application logic to the front-end 
-* A more cohesive fit into the FxA team's stack and processes
+
+- Development speed
+- Better development tooling which is especially important since we intend to move a lot of application logic to the front-end
+- A more cohesive fit into the FxA team's stack and processes
 
 Drivers for starting a new application:
-* Time needed and ease of refactoring the current `rapid` React application vs time needed to start with a new application
+
+- Time needed and ease of refactoring the current `rapid` React application vs time needed to start with a new application
 
 ## Proposed Changes
 
 ### App Directory Tree
 
-Currently, a `static/` directory contains the front-end applications with some shared assets, and a `templates/` directory lives adjacent to it.  To provide a more obvious separation of concerns in the directory tree:
+Currently, a `static/` directory contains the front-end applications with some shared assets, and a `templates/` directory lives adjacent to it. To provide a more obvious separation of concerns in the directory tree:
 
-* Rename `static/` to `legacy-ui/` since `static/rapid/` will become obsolete and `static/core/` will be the legacy Normandy platform¹
-* Move `templates/` into `legacy-ui/` and add a README with historical information
-* Use `create-react-app` to create a new React application in `app/experimenter/nimbus-ui/` with a README for development documentation
+- Rename `static/` to `legacy-ui/` since `static/rapid/` will become obsolete and `static/core/` will be the legacy Normandy platform¹
+- Move `templates/` into `legacy-ui/` and add a README with historical information
+- Use `create-react-app` to create a new React application in `app/experimenter/nimbus-ui/` with a README for development documentation
 
 ¹2020-09-15 clarification: `legacy-ui` will contain the `core` and `rapid` projects. When `nimbus-ui` reaches parity with `rapid`, we can delete the `rapid` directory. Once Nimbus can replace all experimentation moving forward and we either make legacy experiment data available in Nimbus or archive it elsewhere, we can then delete the entire `legacy-ui` directory.
 
 ### Front-End Stack
 
-* Continue using React, but:
-  * Use the `create-react-app` toolchain which gives us Jest, eslint, HMR, and more out of the box
-  * Use Typescript over Proptypes for more strict typing
-  * Use GraphQL for API calls and `apollo-client-cache` for global state management
-  * Use `reach-router` instead of `react-router`
-  * Use directories for components instead of filenames
-    * The Storybook and test file will live adjacent to the component `index.tsx` file which will allow all associated component files to live in the same directory and makes imports shorter.
-    * Keep images inside of the component directory where used until they need to be shared across multiple components
-    * Maintain a flat `src/components/` directory structure for easy imports and file finding, preferring a `NounDescriptor` naming approach to keep similar files together in the tree, such as `PageExperimentForm/` and `PageExperimentDetails/`
-* Continue using Bootstrap (Bootstrap CSS core and `react-bootstrap`), but:
-  * Add stylelint for SCSS linting overrides and document that any custom overrides should be kept very minimal
-  * Use breakpoints established in FxA
-* Utilize Storybook for browsing the UI in various states without running the stack
-* Add Sentry to catch client-side errors
+- Continue using React, but:
+  - Use the `create-react-app` toolchain which gives us Jest, eslint, HMR, and more out of the box
+  - Use Typescript over Proptypes for more strict typing
+  - Use GraphQL for API calls and `apollo-client-cache` for global state management
+  - Use `reach-router` instead of `react-router`
+  - Use directories for components instead of filenames
+    - The Storybook and test file will live adjacent to the component `index.tsx` file which will allow all associated component files to live in the same directory and makes imports shorter.
+    - Keep images inside of the component directory where used until they need to be shared across multiple components
+    - Maintain a flat `src/components/` directory structure for easy imports and file finding, preferring a `NounDescriptor` naming approach to keep similar files together in the tree, such as `PageExperimentForm/` and `PageExperimentDetails/`
+- Continue using Bootstrap (Bootstrap CSS core and `react-bootstrap`), but:
+  - Add stylelint for SCSS linting overrides and document that any custom overrides should be kept very minimal
+  - Use breakpoints established in FxA
+- Utilize Storybook for browsing the UI in various states without running the stack
+- Add Sentry to catch client-side errors
 
 ## Considered Alternatives
 
-* Further front-end and back-end directory tree separation with `app/client/` and `app/server/` directories
-* Refactor existing `rapid` project rather than use CRA for `nimbus-ui`
-* Use existing API calls instead of switching to GQL
-* Use Tailwind instead of Bootstrap
+- Further front-end and back-end directory tree separation with `app/client/` and `app/server/` directories
+- Refactor existing `rapid` project rather than use CRA for `nimbus-ui`
+- Use existing API calls instead of switching to GQL
+- Use Tailwind instead of Bootstrap
 
 ### Positive Consequences
 
-Building the front-end application inside of `app/experimenter/nimbus-ui` and moving the `core` application and templates into `app/experimenter/legacy-ui` allows for better separation of concerns (front-end/back-end, legacy/Nimbus front-end code) while continuing to serve the front-end inside of the Django application. Continuing to use React and Bootstrap while starting a new app with `create-react-app` and GraphQL/Apollo allows us to benefit from stack and tooling improvements while avoiding an entire rewrite of all front-end components.
+Building the front-end application inside of `app/experimenter/nimbus-ui` and moving the `core` application and templates into `app/experimenter/legacy/legacy-ui` allows for better separation of concerns (front-end/back-end, legacy/Nimbus front-end code) while continuing to serve the front-end inside of the Django application. Continuing to use React and Bootstrap while starting a new app with `create-react-app` and GraphQL/Apollo allows us to benefit from stack and tooling improvements while avoiding an entire rewrite of all front-end components.
 
 Some members of the FxA team are rolling off of a React/GQL project, `fxa-settings`, with a similar front-end stack and [good documentation](https://github.com/mozilla/fxa/tree/main/packages/fxa-settings). This project can be referenced for using CRA, Storybook examples, how to set up and use the apollo cache, testing helpers, and testing examples using GQL queries and mutations.
 
 ### Negative Consequences
 
-This approach for `nimbus-ui` will require time to reach parity to the current `rapid` project. 
+This approach for `nimbus-ui` will require time to reach parity to the current `rapid` project.
 
 ## Pros and Cons of the Considered Alternatives
 
@@ -83,43 +86,43 @@ At the time of writing, this has been decided against due to additional set up t
 
 ### Refactor existing project
 
-* Pros
-  * Less time spent on new project scaffolding
-* Cons
-  * Because the `rapid` project is small, this may cause points of frustration and more time than expected shuffling files around, refactoring, modifying tests, and reconnecting the pieces with a new global state management approach compared to starting anew
-  * We desire to use the build pipeline offered and managed by `create-react-app` regardless (see [FxA's React Toolchain ADR](https://github.com/mozilla/fxa/blob/main/docs/adr/0013-react-toolchain-for-settings-redesign.md)) and it may be awkward porting an existing application over
-  * Refactoring instead of "starting fresh" provides a weaker sense of collective ownership from new contributors and excitement for fresh perspectives
+- Pros
+  - Less time spent on new project scaffolding
+- Cons
+  - Because the `rapid` project is small, this may cause points of frustration and more time than expected shuffling files around, refactoring, modifying tests, and reconnecting the pieces with a new global state management approach compared to starting anew
+  - We desire to use the build pipeline offered and managed by `create-react-app` regardless (see [FxA's React Toolchain ADR](https://github.com/mozilla/fxa/blob/main/docs/adr/0013-react-toolchain-for-settings-redesign.md)) and it may be awkward porting an existing application over
+  - Refactoring instead of "starting fresh" provides a weaker sense of collective ownership from new contributors and excitement for fresh perspectives
 
 ### Don't use GQL
 
-* Pros
-  * Less additional work on the front-end and back-end initially
-  * Non-FxA engineers would likely experience a learning curve switching to GQL
-* Cons
-  * As the application grows, we will likely need to set up Redux or grow the current ad-hoc global state management
-  * We won't reap the benefits of a GQL application (see [FxA's GQL ADR](https://github.com/mozilla/fxa/blob/main/docs/adr/0016-use-graphql-and-apollo-for-settings-redesign.md)) such as reduced network requests and data transferred, clarity around expected data and server responses, client-side caching and global state management via `apollo-client-cache`, helpful developer tooling, potentially [GQL subscriptions](https://www.apollographql.com/docs/react/data/subscriptions/), and speedier development in the long run
+- Pros
+  - Less additional work on the front-end and back-end initially
+  - Non-FxA engineers would likely experience a learning curve switching to GQL
+- Cons
+  - As the application grows, we will likely need to set up Redux or grow the current ad-hoc global state management
+  - We won't reap the benefits of a GQL application (see [FxA's GQL ADR](https://github.com/mozilla/fxa/blob/main/docs/adr/0016-use-graphql-and-apollo-for-settings-redesign.md)) such as reduced network requests and data transferred, clarity around expected data and server responses, client-side caching and global state management via `apollo-client-cache`, helpful developer tooling, potentially [GQL subscriptions](https://www.apollographql.com/docs/react/data/subscriptions/), and speedier development in the long run
 
 ### Use Tailwind instead of Bootstrap
 
-* Bootstrap
-  * Pros
-    * Offers a complete UI kit/library to aid in accelerated component styling, leading to less time spent on a custom UI and less time needed on style polishing
-    * Is already being used in the `rapid` project, leading to less component refactoring. With a new `nimbus-ui` application, bits and pieces can likely be copied over
-  * Cons
-    * Isn’t being used in FxA and prevents any potential React component sharing down the line with FxA if we make `fxa-react` more widely available
-    * Is another CSS framework and style pattern for newcomers to pick up on and has a steeper learning curve than other CSS solutions because it offers more
-    * Is a little bulky - we won’t use everything it offers, but this is a much less important consideration for an internal tool like Nimbus
-    * Lacks customization options without forking our own copy or adding style overrides
-* Tailwind
-  * Pros
-    * Has already been setup in `fxa-admin-panel`, `fxa-settings`, and `fxa-react`, meaning 1) it should be straightforward to setup in Nimbus and 2) gives us an option to potentially share React components with FxA (if we make `fxa-react` more widely available)
-    * Developers using it in FxA have given positive feedback on its ease of use
-    * `fxa-settings` has a design guide available for reference and docs written for FxA styling component conventions
-    * Allows us more flexibility without overriding styles on what the overall visual design of the UI will end up as
-  * Cons
-    * Non-FxA engineers may need to ramp up since the `rapid` project is currently using Bootstrap
-    * Will require significant refactoring from what already exists in the `rapid` project
-    * Is a much less complete solution than Bootstrap/`react-bootstrap`, leading to much more time spent on custom UI classes and our own form components
+- Bootstrap
+  - Pros
+    - Offers a complete UI kit/library to aid in accelerated component styling, leading to less time spent on a custom UI and less time needed on style polishing
+    - Is already being used in the `rapid` project, leading to less component refactoring. With a new `nimbus-ui` application, bits and pieces can likely be copied over
+  - Cons
+    - Isn’t being used in FxA and prevents any potential React component sharing down the line with FxA if we make `fxa-react` more widely available
+    - Is another CSS framework and style pattern for newcomers to pick up on and has a steeper learning curve than other CSS solutions because it offers more
+    - Is a little bulky - we won’t use everything it offers, but this is a much less important consideration for an internal tool like Nimbus
+    - Lacks customization options without forking our own copy or adding style overrides
+- Tailwind
+  - Pros
+    - Has already been setup in `fxa-admin-panel`, `fxa-settings`, and `fxa-react`, meaning 1) it should be straightforward to setup in Nimbus and 2) gives us an option to potentially share React components with FxA (if we make `fxa-react` more widely available)
+    - Developers using it in FxA have given positive feedback on its ease of use
+    - `fxa-settings` has a design guide available for reference and docs written for FxA styling component conventions
+    - Allows us more flexibility without overriding styles on what the overall visual design of the UI will end up as
+  - Cons
+    - Non-FxA engineers may need to ramp up since the `rapid` project is currently using Bootstrap
+    - Will require significant refactoring from what already exists in the `rapid` project
+    - Is a much less complete solution than Bootstrap/`react-bootstrap`, leading to much more time spent on custom UI classes and our own form components
 
 Ultimately, Bootstrap was chosen to stick around because Bootstrap CSS and `react-bootstrap` offer a lot of form (and other) components and styles out of the box and the "development speed" decision driver holds significant weight for this project.
 
@@ -128,4 +131,3 @@ Ultimately, Bootstrap was chosen to stick around because Bootstrap CSS and `reac
 [ADR #0001](https://github.com/mozilla/experimenter/blob/main/app/experimenter/docs/adrs/0001-build-nimbus-console-in-experimenter.md) - documented decision to build Nimbus in this repository with the existing Django back-end\
 [graphene-django](https://github.com/graphql-python/graphene-django) - package to allow GraphQL in Python/Django\
 [FxA Settings README](https://github.com/mozilla/fxa/tree/main/packages/fxa-settings) - well-documented project with a similar front-end stack that can be referenced for examples with other relevant ADRs (GQL, React Toolchain) linked at the top
-