chore(DS-462): Add rails-server local dev workflow (#464)

Author: frankhock

README.md

@@ -1,38 +1,38 @@
 # 🌤️ What is the goal of the design system?
 
-The goal of the design system is to achieve visual and experiential consistency throughout the app while streamlining the design and implementation process. The design system should contain all reusable components, one-off variations, and guidelines that are used to build up the existing and future screens of our application. It should direct us to be mindful of when we're consciously diverging from the established system. 
+The goal of the design system is to achieve visual and experiential consistency throughout the app while streamlining the design and implementation process. The design system should contain all reusable components, one-off variations, and guidelines that are used to build up the existing and future screens of our application. It should direct us to be mindful of when we're consciously diverging from the established system.
 
 ## References and inspiration
 - [Carbon - IBM](https://www.carbondesignsystem.com/)
-- [Material Design](https://material.io/design) 
+- [Material Design](https://material.io/design)
 - [Primer - Github](https://primer.style/)
 - [Ant Design](https://ant.design/)
 
 # Updating
 
 ## 🕰️ When do we update the design system?
 
-💚 **Scenario: We need a new component in the design system that is already in the Figma DS, and adding the new component is straightforward and will not significantly affect timeline of the effort.** 
+💚 **Scenario: We need a new component in the design system that is already in the Figma DS, and adding the new component is straightforward and will not significantly affect timeline of the effort.**
 
-We should go ahead and add the new component into Storybook and use the new component in the design. 
+We should go ahead and add the new component into Storybook and use the new component in the design.
 
-⏲️ **Scenario: We need a new component in the design system that is already in the Figma DS, but adding the new component will affect timeline for the effort.** 
+⏲️ **Scenario: We need a new component in the design system that is already in the Figma DS, but adding the new component will affect timeline for the effort.**
 
-We should build the component in a way that will allow for simple transfer into the design system.  Adding the component into the design system should be a follow-on task immediately after the effort. 
+We should build the component in a way that will allow for simple transfer into the design system.  Adding the component into the design system should be a follow-on task immediately after the effort.
 
-🧠 **Scenario: We have a situation where a new component would improve the usability of our design, but it is not yet defined in the Figma DS or in Storybook.** 
+🧠 **Scenario: We have a situation where a new component would improve the usability of our design, but it is not yet defined in the Figma DS or in Storybook.**
 
 These often pop up in the #design-review channel and decisions will depend on designer and development bandwidth. We should strive to make considered designs that continue to push the usability of our app forward while building brand consistency. If there is alignment on a design need, we should add the new component or variation to the Figma DS and add the new component into the design system. If we do not have bandwidth to align on a new design and add the variation to the design system, we should do the best we can with existing patterns.
 
 ## Who makes design system decisions?
 
-Designers can make proposals to update the design system at any point. These changes are submitted to #design-review, and other designers can weigh in with thoughts. There should be a general consensus on why and how the design system should be changed to better suit our needs. Wen is responsible for weighing input and proposing a path forward, looping in JH when necessary. 
+Designers can make proposals to update the design system at any point. These changes are submitted to #design-review, and other designers can weigh in with thoughts. There should be a general consensus on why and how the design system should be changed to better suit our needs. Wen is responsible for weighing input and proposing a path forward, looping in JH when necessary.
 
-On the development side, Dave and Rachel oversee how components are organized and implemented to be put into use most effectively. 
+On the development side, Dave and Rachel oversee how components are organized and implemented to be put into use most effectively.
 
 ## How do we decide whether something is one-off or when the component should be updated universally?
 
-Development-wise, I think we should always strive for universal changes if components are being updated. However, some changes are easily made with confidence that we won't cause issues with the app, while others will require more QA. 
+Development-wise, I think we should always strive for universal changes if components are being updated. However, some changes are easily made with confidence that we won't cause issues with the app, while others will require more QA.
 
 ### Safe to update:
 
@@ -48,13 +48,13 @@ Development-wise, I think we should always strive for universal changes if compo
 
 ## How can we include time for updating components during cycle work?
 
-Keeping the design system relevant is important for consistency in our app. Core product requirements should still take priority, but we should make the design system updates necessary for each effort before tackling nice-to-haves. 
+Keeping the design system relevant is important for consistency in our app. Core product requirements should still take priority, but we should make the design system updates necessary for each effort before tackling nice-to-haves.
 
 ## ✏️ How do we write stories and documentation?
 
-- For every component, we typically separate each variant out into its own story that gets exported. 
+- For every component, we typically separate each variant out into its own story that gets exported.
 - Documentation lives in `Component.mdx` which references stories defined in `Component.stories.jsx`. See documentation style here in [Stories with arbitrary MDX](https://github.com/storybookjs/storybook/blob/master/addons/docs/docs/recipes.md#csf-stories-with-arbitrary-mdx).
-- See our [Storybook Notion Doc](https://www.notion.so/userinterviews1/Storybook-9a3585db57514ec783e39c78518ad5e6) for examples. 
+- See our [Storybook Notion Doc](https://www.notion.so/userinterviews1/Storybook-9a3585db57514ec783e39c78518ad5e6) for examples.
 
 # Future additions to this document
 
@@ -72,7 +72,7 @@ How do we determine whether it's a major, minor, or patch release?
 # Developer Resources
 
 ## Initial Setup
-After cloning the repo, obtain a `.npmrc` file from another developer. This file contains authorization tokens for any private 
+After cloning the repo, obtain a `.npmrc` file from another developer. This file contains authorization tokens for any private
 node packages.
 
 ## Available Scripts
@@ -93,6 +93,18 @@ Runs the jest test suite
 ### `yarn lint`
 
 Runs ESLint to report on any style violations
+
+### `yarn rs:link`
+
+Creates symlinks for packages needed to develop/debug against our `rails-server` repository.
+
+### `yarn rs:link:watch`
+
+Trigger a production build when files are changed.
+
+### `yarn rs:unlink`
+
+Remove symlinked packages.
 ### Visual testing
 
   1. Join BrowserStack (ask Brian for link)
@@ -143,3 +155,29 @@ This package uses [Semantic versioning](https://semver.org/), which requires ver
 * Run `git log $(git describe --tags --abbrev=0)..HEAD --oneline` to get a list of all commits since the latest release and copy these into the "Describe this release" field.
 * Upload the binary that was created from running `npm pack`.
 * Publish release.
+
+## Developing against the Rails Server repo
+
+### Starting up development
+1. run these commands inside the root of the DS repo:
+````bash
+  yarn rs:link && yarn rs:link:watch
+````
+💡 at this point you should see a nodemon process running
+
+2. run these commands inside the root of the RS repo:
+````bash
+  bin/link-ds
+````
+### Wrapping up development
+1. run these commands inside the root of the RS repo:
+````bash
+  bin/unlink-ds
+````
+2. run these commands inside the root of the DS repo:
+````bash
+  yarn rs:unlink
+````
+
+#### 🤔 Snags
+- you'll have to manually refresh your browser tab, after the automatic refresh, to see your expected changes.

bin/link-rs

@@ -0,0 +1,7 @@
+#!/bin/bash
+
+yarn link
+cd node_modules/react
+yarn link
+cd ../../node_modules/react-dom
+yarn link

bin/unlink-rs

@@ -0,0 +1,17 @@
+#!/bin/bash
+
+unlink()
+{
+  local package_name="${2:-$1}"
+
+  output=$(eval "yarn unlink $1")
+
+  echo "$output"
+  echo "== $package_name unlinked =="
+}
+
+unlink '' 'DS package'
+unlink 'react'
+unlink 'react-dom'
+
+yarn install --force

nodemon.json

@@ -0,0 +1,9 @@
+{
+  "exec": "yarn build",
+  "ext": "js,json,jsx,scss",
+  "verbose": true,
+  "watch": [
+    "scss",
+    "src"
+  ]
+}

package.json

@@ -15,6 +15,9 @@
     "build-storybook-docs": "build-storybook -s public --docs",
     "deploy-storybook": "storybook-to-ghpages",
     "prepublishOnly": "yarn build",
+    "rs:link": "bin/link-rs",
+    "rs:link:watch": "./node_modules/nodemon/bin/nodemon.js",
+    "rs:unlink": "bin/unlink-rs",
     "test": "jest"
   },
   "eslintConfig": {
@@ -98,6 +101,7 @@
     "eslint-utils": "^1.4.3",
     "jest": "^26.6.3",
     "node-sass": "4.13.1",
+    "nodemon": "^2.0.15",
     "prop-types": "^15.6.1",
     "react": "16.14.0",
     "react-copy-to-clipboard": "^5.0.2",