Merge pull request #139 from department-of-veterans-affairs/CU/6920-r…

…oettger-DesignSystemEngineeringDoc

[CU] Create baseline engineering documentation

.github/ISSUE_TEMPLATE/contributing.md

@@ -0,0 +1,40 @@
+---
+name: Contributing to the design system
+about: Template for new common component for VA mobile app
+title: 'Component: [Insert name of component here]'
+labels: component-documentation, ux
+assignees:
+---
+
+# Contributing to the design system
+Adding a new component or updating an existing component
+
+## What
+Give a brief description of the component or pattern you want to propose.
+
+## Purpose
+What problem does this component or pattern solve for the user?
+
+## Usage
+**Context or task**: Explain the scenario or user tasks where this component is, or could be, used.
+
+## Behavior
+Describe the key interactions for this component, calling out any specific considerations for mobile.
+
+## Examples
+Include any examples you have of this component or pattern. These can be screenshots, links to a Sketch file, or links to staging or production.
+
+## Accessibility
+Include any accessibility considerations.
+
+## Guidance
+What would you want to tell other teams about this component or pattern?
+
+## Research (optional)
+Include any research you have already conducted, or plan to conduct, on this component or pattern.
+
+## Code (optional)
+Include any existing code.
+
+## Next steps
+After filling out the issue template, post in the Design System slack channel to alert the team that you have filled out an issue. The team will reach out to you with any questions, feedback, and next steps.

README.md

@@ -1,47 +1,3 @@
-# VA Mobile Temporary
+# VA Mobile Libraries
 
-[Read documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/Intro)
-
-
-## Versioning Policy
-The VA Mobile Libraries use [semantic versioning](https://semver.org/) at a per package level.
-
----
-**Guidance in this section to be retired at version 1.0.0**
-
-Despite technically being in production, the design system is still in early, rapidly iterative phases. With only the VA Health & Benefits app leveraging and close team contact, through at least Q1 2024 we plan to use a pre-launch versioning (major version 0) as follows:
-- Version 0.1.0 will be a level set of the package highlighting it's in a workable state with baseline functionality that has been proven consumable by an outside project
-	- For components:  Segmented Control ready to use
-	- For tokens: Baseline set of color tokens available
-	- For other packages: When the package has a core piece of functionality and is stably leveraged by an outside project
-- Any/all breaking changes will be minor version increments with tickets created for the VA Flagship Mobile Team providing specific guidance of necessary adjustments
-- Aside from breaking changes, semver is updated according to long term guidance below
-
-This policy will allow flexibility around anticipated growing pains that may entail more frequent breaking changes than more mature design systems. Once initial adoption challenges have been addressed and the packages have reached a degree of maturity in terms of content, version 1.0.0 will be published and follow the guidelines established below.
-
----
-
-The guidance around versioning for the VA Mobile Libraries shall be as follows:
-- Major
-  - Breaking changes, large or small, that *may* require app-level changes to upgrade; examples:
-	  - Non-backwards compatible update to an existing component property; e.g. renaming or restructuring how data is passed
-	  - Removal of deprecated token(s)/component(s)/etc.
-  - Underlying dependency update introducing incompatibility; e.g. new version of `react-native` that breaks compatibility to app-level version
-  - In exceptional cases, may be incremented for a very significant package enhancement or totality of modest ones that comprise a bonafide "release" even without breaking changes
- - Minor
-	 - Substantive functionality enhancements that are fully backward compatible, examples:
-		 - New token(s)/component(s)/etc.
-		 - Enhancing a component with a new variant
- - Patch
-	 - Minor functionality enhancements that are fully backward compatible, examples:
-		 - Adding a new property of minor impact
-		 - Updating an existing component property with new values that have a minor impact
-		 - Fixing internal bugs
- - Alpha
-	 - Internal design system team testing build denoted by a `-alpha.#` appended to the semver
-	 - Should not be used in production
- - Beta
-	 - External team testing build denoted by a `-beta.#` appended to the semver
-	 - Should not be used in production outside exceptional circumstances
-
-The Figma Design Library will also follow this versioning guidance except only reflecting major/minor levels. Patch changes are likely to result in no visual changes or the design was correct while minor technical tweaks were made.
+See the [Design System section of the VA Mobile documentation site](https://department-of-veterans-affairs.github.io/va-mobile-app/design/Intro) for the most organized form of the documentation. The [engineering documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/For%20engineers/overview) there also exists in this repo either in the `documentation` folder or as `README`'s tied to particular packages.

documentation/README.md

@@ -0,0 +1 @@
+A folder for general design system documentation not specifically tied to a package.

documentation/contributing.md

@@ -0,0 +1,23 @@
+# Contributing Code
+
+If your contribution entails adding an entirely new component or significant enhancement of an existing component, [please see the general guidance to contributing](https://department-of-veterans-affairs.github.io/va-mobile-app/design/About/Contributing%20to%20the%20design%20system/contributing-to-the-design-system). Given larger enhancements will entail designer input throughout the process, discussions will precede any need for code contributions which will be able to clarify expectations.
+
+If you are looking to contribute a bugfix or minor change you don't believe needs that process:
+1. [Search our outstanding issues](https://github.com/department-of-veterans-affairs/va-mobile-library/issues) to determine if it's already on our radar or a new ticket needs to be created
+2. Notify us in [our DSVA slack channel](https://dsva.slack.com/archives/C05HF9ULKJ4) to:
+    - Determine if we have a timeline to prioritize if a ticket already exists
+    - Open a conversation around your intent to contribute a small change
+3. If the Slack conversation gives the go ahead to move forward, either assign yourself to the existing ticket or create the new ticket and assign it to yourself
+4. If appropriate, update the Slack thread with the newly created ticket
+5. Move ticket to in progress
+6. See individual package documentation for how to get it running locally to code/test your changes
+
+Factors to keep in mind during coding for a smooth PR:
+- Look over [our PR template](https://github.com/department-of-veterans-affairs/va-mobile-library/blob/main/.github/pull_request_template.md?plain=1) for awareness of write-up expectations
+- Observe existing code structure and aim to minimize complexity and maintain consistency unless you feel it could be meaningfully improved--if so, consider using Slack to discuss more robust code restructure changes prior to making them
+- If appropriate:
+    - Update/add unit tests
+    - Update/add code documentation
+    - Update/add storybook stories
+    - Create alpha testing package build(s) to test within your app it behaves as expected with your changes
+        - Note: alpha builds should never be used in production, if it is time critical it should be a beta build and be a very temporary fix until a proper version can be published

documentation/overview.md

@@ -0,0 +1,49 @@
+# Overview
+
+Welcome to the engineering section of the VA Mobile Design System documentation!
+
+First things first: from an engineering perspective, what is the design system?
+
+Fundamentally, the design system is a collection of NPM packages that can be added to a project like any other. These packages are created to support making native mobile apps that adhere to VA design principles, provide an accessible user experience, and streamline app development by providing UI building blocks to maximize time for delivering features. 
+
+Currently and on the roadmap for foreseeable future, the mobile design system components rely on React Native--the most popular mobile framework for complex, multiplatform native mobile apps.
+
+The VA Mobile Design System is in early stages and far from maturity; as such, feedback on experience using the packages and this documentation is very welcomed to continually improve the experience! The ideal avenue for feedback is our [DSVA Slack channel](https://dsva.slack.com/archives/C05HF9ULKJ4) (#va-mobile-app-shared-systems).
+
+Lastly, the [va-mobile-library repo](https://github.com/department-of-veterans-affairs/va-mobile-library) houses the VA Mobile Design System codebase and [our Storybook](https://department-of-veterans-affairs.github.io/va-mobile-library/) demonstrates them functionally.
+
+## Packages
+
+So, what is currently being offered? 
+
+Our packages:
+- assets
+  - Package containing static assets (e.g. fonts, SVG icons) for VA mobile apps
+  - Peer dependency (required) to components for appropriate function
+  - [Documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/For%20engineers/assets)
+  - [NPM](https://www.npmjs.com/package/@department-of-veterans-affairs/mobile-assets)
+  - [Code](https://github.com/department-of-veterans-affairs/va-mobile-library/tree/main/packages/assets)
+- components
+  - Package containing the components of the design system
+  - [Documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/For%20engineers/components)
+  - [NPM](https://www.npmjs.com/package/@department-of-veterans-affairs/mobile-component-library)
+  - [Code](https://github.com/department-of-veterans-affairs/va-mobile-library/tree/main/packages/components)
+- linting
+  - Package containing an eslint plugin to issue deprecation notices as part of linting
+  - [Documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/For%20engineers/linting)
+  - [NPM](https://www.npmjs.com/package/@department-of-veterans-affairs/eslint-config-mobile)
+  - [Code](https://github.com/department-of-veterans-affairs/va-mobile-library/tree/main/packages/linting)
+- tokens
+  - Package containing atomic, tokenized building blocks used for components so any app can build screens or custom components adhering to the same underlying styling fundamentals
+  - [Documentation](https://department-of-veterans-affairs.github.io/va-mobile-app/design/For%20engineers/tokens)
+  - [NPM](https://www.npmjs.com/package/@department-of-veterans-affairs/mobile-tokens)
+  - [Code](https://github.com/department-of-veterans-affairs/va-mobile-library/tree/main/packages/tokens)
+
+Each package's documentation page contains more specialized guidance both for consumers of the package as well as for contributing.
+
+All packages use [ISC licenses](https://en.wikipedia.org/wiki/ISC_license):
+> Copyright 2023 Department of Veterans Affairs
+> 
+> Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
+> 
+> THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

documentation/testing.md

@@ -0,0 +1,32 @@
+# Testing
+
+## Testing component package integrations
+
+Before a new component, or new version of an old component, is released it should be tested inside an example environment that it will be consuming. For this purpose we can use the [VA Flagship app](https://github.com/department-of-veterans-affairs/va-mobile-app). We can do this both with automation and manual testing.
+
+### Automatically
+
+We will have automated checks run on the components where we can. For our main client, the VA Flagship app we currently have [a Github actions workflow](https://github.com/department-of-veterans-affairs/va-mobile-library/blob/main/.github/workflows/check-component-integrations.yml) that will run each time a pull request is merged into the `main` branch. This automated workflow will simulate the VA Flagship app using the latest component package and run any associated tests to ensure no unintentional breakage happens. The workflow can also be run manually from the [Check Component Integrations action](https://github.com/department-of-veterans-affairs/va-mobile-library/actions/workflows/check-component-integrations.yml).
+
+As more clients are added to the system, more tests will be added to the workflow. The tests themselves are managed by the client team and any app included (at this time) needs to be in a publicly accessible repository.
+
+Automated tests will be able to check each instance of the component, so it is also important to manually test component integrations where appropriate.
+
+### Manually
+
+The preferred method for manual testing is [to create an alpha build via the NPM publish workflow](https://github.com/department-of-veterans-affairs/va-mobile-library/actions/workflows/publish.yml) of the package from your branch and then update your project locally to leverage that alpha build to test. Note: alpha builds should never be used in production.
+
+There are a couple additional methods to manually check if a component works inside an app environment, but neither works as well as the preferred method and may not behave the same as a published package (e.g. changes may work using these methods that would _not_ work in a published NPM package): 
+<details>
+<summary>Alternate Method 1</summary>
+The first option is to manually install the local component into the app you're testing in by running: <code>yarn add file:../../va-mobile-library/packages/components</code> (assumes va-mobile-app and va-mobile-library are siblings, if they are not, change the path). This method points directly to the component file you're testing. The downside here is that your watch command may not work, so you'll need to rebuild the app to see changes (or update the watch configuration).
+
+</details>
+
+<details>
+<summary>Alternate Method 2</summary>
+The second is to use <a href="https://classic.yarnpkg.com/lang/en/docs/cli/link/">local dependency linking through yarn commands</a>. This creates a symlink to the local component from the app. There are some <a href="https://github.com/facebook/metro/issues/1">Metro config changes that need to happen for this to work</a> and support is a little iffy at the moment, but it's certainly an option, although not highly recommended at this point.
+
+</details>
+
+With all methods above, you can validate things have installed correctly looking up the `@department-of-veterans-affairs/mobile-component-library` folder within your package folder (e.g. `node_modules`) and validating the correct package version is present. You can then run all app-level tests on it (manual app use, unit, compiling, e2e). The level of testing needed will be defined by the size of the update that is being made.

documentation/versioning.md

@@ -0,0 +1,42 @@
+# Versioning Policy
+The VA Mobile Libraries use [semantic versioning](https://semver.org/) at a per package level.
+
+---
+**Guidance in this section to be retired at version 1.0.0**
+
+Despite technically being in production, the design system is still in early, rapidly iterative phases. With only the VA Health & Benefits app leveraging and close team contact, through at least Q1 2024 we plan to use a pre-launch versioning (major version 0) as follows:
+- Version 0.1.0 will be a level set of the package highlighting it's in a workable state with baseline functionality that has been proven consumable by an outside project
+	- For components:  Segmented Control ready to use
+	- For tokens: Baseline set of color tokens available
+	- For other packages: When the package has a core piece of functionality and is stably leveraged by an outside project
+- Any/all breaking changes will be minor version increments with tickets created for the VA Flagship Mobile Team providing specific guidance of necessary adjustments
+- Aside from breaking changes, semver is updated according to long term guidance below
+
+This policy will allow flexibility around anticipated growing pains that may entail more frequent breaking changes than more mature design systems. Once initial adoption challenges have been addressed and the packages have reached a degree of maturity in terms of content, version 1.0.0 will be published and follow the guidelines established below.
+
+---
+
+The guidance around versioning for the VA Mobile Libraries shall be as follows:
+- Major
+  - Breaking changes, large or small, that *may* require app-level changes to upgrade; examples:
+	  - Non-backwards compatible update to an existing component property; e.g. renaming or restructuring how data is passed
+	  - Removal of deprecated token(s)/component(s)/etc.
+  - Underlying dependency update introducing incompatibility; e.g. new version of `react-native` that breaks compatibility to app-level version
+  - In exceptional cases, may be incremented for a very significant package enhancement or totality of modest ones that comprise a bonafide "release" even without breaking changes
+ - Minor
+	 - Substantive functionality enhancements that are fully backward compatible, examples:
+		 - New token(s)/component(s)/etc.
+		 - Enhancing a component with a new variant
+ - Patch
+	 - Minor functionality enhancements that are fully backward compatible, examples:
+		 - Adding a new property of minor impact
+		 - Updating an existing component property with new values that have a minor impact
+		 - Fixing internal bugs
+ - Beta
+	 - External team testing build denoted by a `-beta.#` appended to the semver
+	 - Should not be used in production outside exceptional circumstances
+  - Alpha
+	 - Internal design system team testing build denoted by a `-alpha.#` appended to the semver
+	 - Should not be used in production
+
+The Figma Design Library will also follow this versioning guidance except only reflecting major/minor levels. Patch changes are likely to result in no visual changes or the design was correct while minor technical tweaks were made.