Personal Property Prototype

This repository contains the application source code for the Personal Property Prototype, a possible next generation version of the Defense Personal Property System (DPS). DPS is an online system managed by the U.S. Department of Defense (DoD) Transportation Command (USTRANSCOM) and is used by service members and their families to manage household goods moves.

This prototype was built by a Defense Digital Service team in support of USTRANSCOM's mission.

License Information

Works created by U.S. Federal employees as part of their jobs typically are not eligible for copyright in the United States. In places where the contributions of U.S. Federal employees are not eligible for copyright, this work is in the public domain. In places where it is eligible for copyright, such as some foreign jurisdictions, the remainder of this work is licensed under the MIT License, the full text of which is included in the LICENSE.txt file in this repository.

Overview
Supported Browsers
Login.gov
Application Setup
Development

Regenerate with "pre-commit run -a markdown-toc"

Overview

MilMove is a system to help service members (and other authorized personnel) move their gear and possessions from one place to another.

The TLS apps

There are three React apps that compose the front end of the system:

my.move.mil (my.staging.move.mil): For the people moving.

office.move.mil (office.staging.move.mil): For move managers (see historical note) to review/approve/reject moves and payments.

admin.move.mil (admin.staging.move.mil): For administrators to create new office.move.mil users and grant permissions for various office roles.

These React apps are backed by a Postgres database, which we interact with using a back-end written in Go, with an ORM called Pop.

We use Swagger to tie the front and back ends together. The Swagger code is found in *.yaml files and describes the endpoints and payloads of the API.

Go boilerplate code is generated from the Swagger files using a library called go-swagger. That code is automatically updated when a Swagger file is changed. These generated files are in /pkg/gen.

Swagger has interactive documentation for users of the API, which allows us to test endpoints from within the doc itself.

Swagger also has a JS client that generates a set of API functions that are hooked into the React apps giving them easier access to the data.

The Mutual TLS apps

In addition to the front end interfaces, MilMove comprises a set of APIs that work over Mutual TLS:

Contractors: The API the GHC contractor will use to communicate with the system. When the contractor needs information about a move (e.g., when is it scheduled?) or needs to update information about a move (e.g., what was the total weight of items moved?), it will use the Contractors API. As of this writing, this API is described in prime.yaml, but expect that name to change.

Orders: People moving receive orders to move, which include information about the destination as well as authorizations for various kinds of storage, conveyance, per diem allowances, and many more details. Currently Orders information is entered into the system manually by office personnel from a PDF. However, the Orders API is receiving that data directly from the services and eventually that data will be used as the source of truth. That process is called "Orders Ingestion". The process of getting that data into the system for use with moves is called "Orders Integration".

GEX: Global Exchange. GEX enables the exchange of transaction data between the DoD and private entities. We use it during the invoicing phase of the move.

DPS: This is also the name of the system MilMove is replacing, but in terms of APIs, DPS acts as an authenticator that will route a user to DPS or MilMove, as appropriate.

Historical note

The history of the project is detailed in the MilMove onboarding document, but one thing for application engineers to keep in mind is that as of this writing, in early 2020, there are two different supported approaches to moves, with one being phased out, but still present in parts of the code. The old model of moves included PPM (Personally Procured Moves--do it yourself and get reimbursed) and HHG (HouseHold Goods moves--the government hires a moving company for you). In that rubric, there was no explicit role system for office app users. We are now phasing out HHG moves in favor of GHC (Global Household goods Contract) moves, in which a single company will handle all subcontracting for moves and explicit roles, like Transportation Ordering Officer (TOO) and Transportation Invoicing Officer (TIO), are defined and assigned.

Supported Browsers

As of 3/6/2018, DDS has confirmed that support for IE is limited to IE 11 and Edge or newer versions. Currently, the intention is to encourage using Chrome and Firefox instead, with specific versions TBD. Research is incomplete on mobile browsers, but we are assuming support for iOS and Android. For more information please read ADR0016 Browser Support.

Login.gov

You'll need accounts for login.gov and the login.gov sandbox. These will require two-factor authentication, so have your second factor (one of: phone, authentication app, security key, CAC) on hand. To create an account at login.gov, use your regular truss.works email and follow the official instructions. To create an account in the sandbox, follow the same instructions, but in the sandbox server. Do not use your regular email address in the sandbox. Tip: You can use the plus sign + to create a new truss email address. name+some_string@truss.works will be treated as a new address, but will be routed to name@truss.works.

Application Setup

Setup: Developer Setup

There are a number of things you'll need at a minimum to be able to check out, develop and run this project.

Install Homebrew
- Use the following command /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
We normally use the latest version of Go unless there's a known conflict (which will be announced by the team) or if we're in the time period just after a new version has been released.
- Install it with Homebrew: brew install go
- Note: If you have previously modified your PATH to point to a specific version of go, make sure to remove that. This would be either in your .bash_profile or .bashrc, and might look something like PATH=$PATH:/usr/local/opt/go@1.12/bin.
Ensure you are using the latest version of bash for this project:
- Install it with Homebrew: brew install bash
- Update list of shells that users can choose from: [[ $(cat /etc/shells | grep /usr/local/bin/bash) ]] || echo "/usr/local/bin/bash" | sudo tee -a /etc/shells
- If you are using bash as your shell (and not zsh, fish, etc) and want to use the latest shell as well then change it (optional): chsh -s /usr/local/bin/bash
- Ensure that /usr/local/bin comes before /bin on your $PATH by running echo $PATH. Modify your path by editing ~/.bashrc or ~/.bash_profile and changing the PATH. Then source your profile with source ~/.bashrc or ~/.bash_profile to ensure that your terminal has it.

Setup: Git

Use your work email when making commits to our repositories. The simplest path to correctness is setting global config:

git config --global user.email "trussel@truss.works"
git config --global user.name "Trusty Trussel"

If you drop the --global flag these settings will only apply to the current repo. If you ever re-clone that repo or clone another repo, you will need to remember to set the local config again. You won't. Use the global config. :-)

For web-based Git operations, GitHub will use your primary email unless you choose "Keep my email address private". If you don't want to set your work address as primary, please turn on the privacy setting.

Note that with 2-factor-authentication enabled, in order to push local code to GitHub through HTTPS, you need to create a personal access token and use that as your password.

Setup: Golang

All of Go's tooling expects Go code to be checked out in a specific location. Please read about Go workspaces for a full explanation. If you just want to get started, then decide where you want all your go code to live and configure the GOPATH environment variable accordingly. For example, if you want your go code to live at ~/code/go, you should add the following like to your .bash_profile:

export GOPATH=~/code/go

Golang expect the GOPATH environment variable to be defined. If you'd like to use the default location, then add the following to your .bash_profile or hardcode the default value. This line will set the GOPATH environment variable to the value of go env GOPATH if it is not already set.

export GOPATH=${GOPATH:-$(go env GOPATH)}

Regardless of where your go code is located, you need to add $GOPATH/bin to your PATH so that executables installed with the go tooling can be found. Add the following to your .bash_profile:

export PATH=$(go env GOPATH)/bin:$PATH

Finally to have these changes applied to your shell you must source your profile:

source ~/.bash_profile

You can confirm that the values exist with:

env | grep GOPATH
# Verify the GOPATH is correct
env | grep PATH
# Verify the PATH includes your GOPATH bin directory

Setup: Project Checkout

You can checkout this repository by running git clone git@github.com:transcom/mymove.git. Please check out the code in a directory like ~/Projects/mymove and NOT in your $GOPATH. As an example:

mkdir -p ~/Projects
git clone git@github.com:transcom/mymove.git
cd mymove

You will then find the code at ~/Projects/mymove. You can check the code out anywhere EXCEPT inside your $GOPATH. So this is customization that is up to you.

Setup: Project Layout

All of our code is intermingled in the top level directory of mymove. Here is an explanation of what some of these directories contain:

.circleci: Directory for CircleCI CI/CD configuration
bin: A location for tools compiled from the cmd directory
build: The build output directory for the client. This is what the development server serves
cmd: The location of main packages for any go binaries we build
config: Config files for the database and AWS ECS. Also certificates.
cypress: The integration test files for the Cypress tool
docs: A location for docs for the project. This is where ADRs are
internal: Generated code for duty station loader
migrations: Database migrations, see [./migrations/README.md]
node_modules: Cached javascript dependencies for the client
pkg: The location of all of our go code for the server and various tools
public: The client's static resources
scripts: A location for tools helpful for developing this project
src: The react source code for the client
swagger: The swagger definition files for each of our APIs

Setup: Editor Config

EditorConfig allows us to manage editor configuration (like indent sizes,) with a file in the repo. Install the appropriate plugin in your editor to take advantage of that if you wish.

Setup: Makefile

The primary way to interact with the project is via the Makefile. The Makefile contains a number of handy targets (you can think of these as commands) that make interacting with the project easier. Each target manages its own dependencies so that you don't have to. This is how you'll do common tasks like build the project, run the server and client, and manage the database.

The fastest way to get familiar with the Makefile is to use the command make help. You can also type make and it will default to calling make help target on your behalf. The Makefile is important to this project so take the time to understand what it does.

Setup: Quick Initial Setup

The following commands will get mymove running on your machine for the first time. This is an abbreviated list that should get you started. Please read below for explanations of each of the commands.

make prereqs
direnv allow
make ensure_pre_commit
make deps
make db_dev_run
make db_dev_migrate
make server_run
make client_build
make client_run

Setup: Prerequisites

Run make prereqs and install everything it tells you to. Most of the prerequisites need you to use brew install <package>.

NOTE: Do not configure PostgreSQL to automatically start at boot time or the DB commands will not work correctly!

Setup: Direnv

For managing local environment variables, we're using direnv. You need to configure your shell to use it. For bash, add the command eval "$(direnv hook bash)" to whichever file loads upon opening bash (likely ~/.bash_profile, though instructions say ~/.bashrc). For zsh, add eval "$(direnv hook zsh)" to ~/.zshrc.

Run direnv allow to load up the .envrc file. It should complain that you have missing variables which you will rectify in one of the following ways.

You can add a .envrc.local file. One way to do this is using the chamber tool to read secrets from AWS vault. Then run chamber env app-devlocal >> .envrc.local. If you don't have access to chamber you can also touch .envrc.local and add any values that the output from direnv asks you to define. Instructions are in the error messages.

If you wish to not maintain a .envrc.local you can alternatively run cp .envrc.chamber.template .envrc.chamber to enable getting secret values from chamber. Note that this method does not work for users of the fish shell unless you replace direnv allow with direnv export fish | source.

Helpful variables for `.envrc.local`

export GOLANGCI_LINT_CONCURRENCY=8 - variable to increase concurrency of golangci-lint; defaults to 6 on dev machines and to 1 in CircleCI.
export GOLAND=1 - variable to enable go code debugging in goland

Setup: Pre-Commit

Run pre-commit install to install a pre-commit hook into ./git/hooks/pre-commit. This is different than brew install pre-commit and must be done so that the hook will check files you are about to commit to the repository. Next install the pre-commit hook libraries with pre-commit install-hooks.

Before running pre-commit run -a you will need to install Javascript dependencies and generate some golang code from Swagger files. An easier way to handle this is by running make pre_commit_tests or make server generate client_deps && pre-commit run -a. But it's early to do this so you can feel free to skip running the pre-commit checks at this time.

Setup: Hosts

You need to modify your /etc/hosts file. This is a tricky file to modify and you will need to use sudo to edit it. Here are the steps:

echo "127.0.0.1 milmovelocal" | sudo tee -a /etc/hosts
echo "127.0.0.1 officelocal" | sudo tee -a /etc/hosts
echo "127.0.0.1 orderslocal" | sudo tee -a /etc/hosts
echo "127.0.0.1 adminlocal" | sudo tee -a /etc/hosts
echo "127.0.0.1 primelocal" | sudo tee -a /etc/hosts

Check that the file looks correct with cat /etc/hosts:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost
127.0.0.1   localhost
127.0.0.1   milmovelocal
127.0.0.1   officelocal
127.0.0.1   orderslocal
127.0.0.1   adminlocal
127.0.0.1   primelocal

You can also verify this by running scripts/check-hosts-file.

Setup: Dependencies

Run make deps. This will check your system for any setup issues. Then it will ensure that you have installed pre-commit and go on to install the client (javascript) and server (golang) dependencies for you.

Setup: Build Tools

Run make build_tools to get all the server and tool dependencies built. These will be needed in future steps to not only generate test data but also to interact with the database and more.

Setup: Database

You will need to setup a local database before you can begin working on the local server / client. Docker will need to be running for any of this to work.

make db_dev_run: Creates a PostgreSQL docker container if you haven't made one yet
make db_dev_migrate: Runs all existing database migrations, which does things like creating table structures, etc. You will run this command again anytime you add new migrations to the app (see below for more)

You can validate that your dev database is running by running psql-dev. This puts you in a PostgreSQL shell. Type \dt to show all tables, and \q to quit. You can validate that your test database is running by running psql-test. This puts you in a PostgreSQL shell. Type \dt to show all tables, and \q to quit.

If you are stuck on this step you may need to see the section on Troubleshooting.

Setup: Server

make server_run: installs dependencies, then builds and runs the server using gin, which is a hot reloading go server. It will listen on 8080 and will rebuild the actual server any time a go file changes. Pair this with make client_run to have hot reloading of the entire application.

In rare cases, you may want to run the server standalone, in which case you can run make server_run_standalone. This will build both the client and the server and this invocation can be relied upon to be serving the client JS on its own rather than relying on webpack doing so as when you run make client_run. You can run this without running make client_run and the whole app should work.

Dependencies are managed by go modules. New dependencies are automatically detected in import statements and added to go.mod when you run go build or go run. You can also manually edit go.mod as needed.

If you need to add a Go-based tool dependency that is otherwise not imported by our code, import it in pkg/tools/tools.go.

After importing any go dependency it's a good practice to run go mod tidy, which prunes unused dependencies and calculates dependency requirements for all possible system architectures.

Setup: MilMoveLocal Client

make client_build (if setting up for first time)
make client_run

The above will start the webpack dev server, serving the front-end on port 3000. If paired with make server_run then the whole app will work, the webpack dev server proxies all API calls through to the server.

If both the server and client are running, you should be able to view the Swagger UI at http://milmovelocal:3000/api/v1/docs. If it does not, try running make client_build (this only needs to be run the first time).

Dependencies are managed by yarn. To add a new dependency, use yarn add

Setup: OfficeLocal client

Ensure that you have a test account which can log into the office site...
- run generate-test-data --named-scenario e2e_basic to load test data
- Log into "Local Sign In" and either select a pre-made user or use the button to create a new user
make office_client_run
Login with the email used above to access the office

Setup: AdminLocal client

make admin_client_run

Setup: DPS user

Ensure that you have a login.gov test account
Log into MilMove Devlocal Auth and create a new DPS user from the interface.

Setup: Orders Gateway

Nothing to do.

Setup: Prime API

The API that the Prime will use is authenticated via mutual TSL so there are a few things you need to do to interact with it in a local environment.

Make sure that the primelocal alias is setup for localhost. See Setup:Hosts
run make server_run
Access the Prime API using the devlocal-mtls certs. There is a script that shows you how to do this with curl at ./scripts/prime-api. For instance to call the move-task-orders endpoint, call ./scripts/prime-api move-task-orders

Setup: AWS Services (Optional)

If you want to develop against AWS services you will need an AWS user account with engineering privileges.

AWS credentials are managed via aws-vault. See the the instructions in transcom-ppp to set things up.

Development

TSP Award Queue

This background job is built as a separate binary which can be built using make tsp_run.

Test Data Generator

When creating new features, it is helpful to have sample data for the feature to interact with. The TSP Award Queue is an example of that--it matches shipments to TSPs, and it's hard to tell if it's working without some shipments and TSPs in the database!

make bin/generate-test-data will build the fake data generator binary
bin/generate-test-data -named-scenario="e2e_basic" will populate the database with a handful of users in various stages of progress along the flow. The emails are named accordingly (see e2ebasic.go). Alternatively, run make db_dev_e2e_populate to reset your db and populate it with e2e user flow cases.
bin/generate-test-data will run binary and create a preconfigured set of test data. To determine the data scenario you'd like to use, check out scenarios in the testdatagen package. Each scenario contains a description of what data will be created when the scenario is run. Pass the scenario in as a flag to the generate-test-data function. A sample command: ./bin/generate-test-data -scenario=2.

There is also a package (/pkg/testdatagen) that can be imported to create arbitrary test data. This could be used in tests, so as not to duplicate functionality.

Currently, scenarios have the following numbers:

-scenario=1 for Award Queue Scenario 1
-scenario=2 for Award Queue Scenario 2
-scenario=3 for Duty Station Scenario
-scenario=4 for PPM or PPM SIT Estimate Scenario (can also use Rate Engine Scenarios for Estimates)
-scenario=5 for Rate Engine Scenario 1
-scenario=6 for Rate Engine Scenario 2
-scenario=7 for TSP test data

API / Swagger

The public API is defined in a single file: swagger/api.yaml and served at /api/v1/swagger.yaml. This file is the single source of truth for the public API.

In addition, internal services, i.e. endpoints only intended for use by the React client are defined in swagger/internal.yaml and served at /internal/swagger.yaml. These are, as the name suggests, internal endpoints and not intended for use by external clients.

The Orders Gateway's API is defined in the file swagger/orders.yaml and served at /orders/v0/orders.yaml.

The Admin API is defined in the file swagger/admin.yaml and served at /admin/v1/swagger.yaml.

You can view the API's documentation (powered by Swagger UI) at http://localhost:3000/api/v1/docs when a local server is running.

Testing

There are a few handy targets in the Makefile to help you run tests:

make client_test: Run front-end testing suites.
make server_test: Run back-end testing suites. Additional info for running go tests
make e2e_test: Run e2e testing suite.
make test: Run e2e, client- and server-side testing suites.

Logging

We are using zap as a logger in this project. We currently rely on its built-in NewDevelopment() and NewProduction() default configs, which are enabled in any of the executable packages that live in cmd.

This means that logging is not set up from within models or other packages unless the files in cmd are also being loaded. If you attempt to call zap.L() or zap.S() without a configured logger, nothing will appear on the screen.

If you need to see some output during the development process (say, for debugging purposes), it is best to use the standard lib fmt package to print to the screen. You will also need to pass -v to go test so that it prints all output, even from passing tests. The simplest way to do this is to run go test yourself by passing it which files to run, e.g. go test pkg/models/* -v.

Log files

In development mode, logs from the milmove process are written to logs/dev.log.

Database

Read Querying the Database Safely to prevent SQL injections! *

A few commands exist for starting and stopping the DB docker container:

make db_run: Starts the DB docker container if one doesn't already exist
make db_destroy: Stops and removes the DB docker container

Dev DB Commands

There are a few handy targets in the Makefile to help you interact with the dev database:

make db_dev_run: Initializes a new database if it does not exist and runs it, or starts the previously initialized Docker container if it has been stopped.
make db_dev_create: Waits to connect to the DB and will create a DB if one doesn't already exist (run usually as part of db_dev_run).
make db_dev_reset: Destroys your database container. Useful if you want to start from scratch.
make db_dev_migrate: Applies database migrations against your running database container.
make db_dev_migrate_standalone: Applies database migrations against your running database container but will not check for server dependencies first.
make db_dev_e2e_populate: Populate data with data used to run e2e tests

Test DB Commands

The Dev Commands are used to talk to the dev DB. If you were working with the test DB you would use these commands:

make db_test_run
make db_test_create
make db_test_reset
make db_test_migrate
make db_test_migrate_standalone
make db_test_e2e_populate
make db_test_e2e_backup
make db_test_e2e_restore
make db_test_e2e_cleanup

The test DB commands all talk to the DB over localhost. But in a docker-only environment (like CircleCI) you may not be able to use those commands, which is why *_docker versions exist for all of them:

make db_test_run_docker
make db_test_create_docker
make db_test_reset_docker
make db_test_migrate_docker

Migrations

To add new regular and/or secure migrations, see the database development guide

Running migrations in local development:

Use make db_dev_migrate to run migrations against your local dev environment.

Running migrations on Staging / Production:

Migrations are run automatically by CircleCI as part of the standard deploy process.

CircleCI builds and registers a container.
CircleCI deploys this container to ECS and runs it as a one-off 'task'.
The container downloads and execute migrations against the environment's database.
If migrations fail, CircleCI fails the deploy.
If migrations pass, CircleCI continues with the deploy.

Environment Variables

In development, we use direnv to setup environment variables required by the application.

If you want to add a new environment variable to affect only your development machine, export it in .envrc.local. Variables exported in this file take precedence over those in .envrc.

If you want to add a new environment variable that is required by new development, it can be added to .envrc using one of the following:

# Add a default value for all devs that can be overridden in their .envrc.local
export NEW_ENV_VAR="default value"

# or

# Specify that an environment variable must be defined in .envrc.local
require NEW_ENV_VAR "Look for info on this value in chamber and Google Drive"

Required variables should be placed in google docs and linked in .envrc. The value should also be placed in chamber with chamber write app-devlocal <key> <value>. For long blocks of text like certificates you can write them with echo "$LONG_VALUE" | chamber write app-devlocal <key> -.

For per-tier environment variables (that are not secret), simply add the variables to the relevant config/env/[experimental|staging|prod].env file with the format NAME=VALUE on each line. Then add the relevant section to config/app.container-definition.json. The deploy process uses Go's template package for rendering the container definition. For example,

MY_SPECIAL_TOKEN=abcxyz

{
  "name": "MY_SPECIAL_TOKEN",
  "value": "{{ .MY_SPECIAL_TOKEN }}"
},

Documentation

You can view the project's GoDoc on godoc.org.

Alternatively, run the documentation locally using:

# within the project's root dir
$ godoc -http=:6060

Then visit http://localhost:6060/pkg/github.com/transcom/mymove/

Spellcheck

We use markdown-spellcheck as a pre-commit hook to catch spelling errors in Markdown files. To make fixing caught errors easier, there's a handy make target that runs the spellchecker in interactive mode:

make spellcheck

This will let you walk through the caught spelling errors one-by-one and choose whether to fix it, add it to the dictionary, or have it be permanently ignored for that file.

Tips for staying sane

If you want to use a bare hyperlink, wrap it in angle braces: <http://example.com>

GoLand

GoLand supports attaching the debugger to a running process, however this requires that the server has been built with specific flags. If you wish to use this feature in development add the following line export GOLAND=1 to your .envrc.local. Once the server starts follow the steps outlined in the article above and you should now be able to set breakpoints using the GoLand debugger.

Troubleshooting

Random problems may arise if you have old Docker containers running. Run docker ps and if you see containers unrelated to our app, consider stopping them.
If you happen to have installed pre-commit in a virtual environment not with brew, running make prereqs will not alert you. You may run into issues when running make deps. To install pre-commit: brew install pre-commit.
If you're having trouble accessing the API docs or the server is otherwise misbehaving, try stopping the server, running make client_build, and then running make client_run and make server_run.

Postgres Issues

If you have problems connecting to PostgreSQL, or running related scripts, make sure you aren't already running a PostgreSQL daemon. You may see errors like:

Migrator: problem creating schema migrations: couldn't start a new transaction: could not create new transaction: pq: role "postgres" does not exist

Migrator: problem creating schema migrations: couldn't start a new transaction: could not create new transaction: pq: database "dev_db" does not exist

You can check this by typing ps aux | grep postgres or brew services list and looking for existing processes. In the case of homebrew you can run brew services stop postgresql to stop the service and prevent it from running at startup.

Development Machine Timezone Issues

If you are experiencing problems like redux forms that are 'dirty' when they shouldn't be on your local environment, it may be due to a mismatch of your local dev machine's timezone and the assumption of UTC made by the local database. A detailed example of this sort of issue can be found in this story. A workaround for this is to set the TZ environment variable in Mac OS for the context of your running app. This can be done by adding the following to .envrc.local:

export TZ="UTC"

Doing so will set the timezone environment variable to UTC utilizing the same localized context as your other .envrc.local settings.

Linters & Pre-commit Hooks

We use a number of linters for formatting, security and error checking. Please see this how-to document for a list of linters and troubleshooting tips.

Yarn install markdown-spell (aka mdspell)

We use mdspell for spell checking markdown files during pre-commit hooks. You may run into an issue such as below during the installation command yarn global add markdown-spellcheck suggested by the Makefile.

Example error:

>$ yarn global add markdown-spellcheck

yarn global v1.19.0
[1/4] :mag:  Resolving packages...
[2/4] :truck:  Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/har-validator/-/har-validator-5.1.2.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/Users/john/.config/yarn/global/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/global for documentation about this command.

If you do, following these steps may resolve it.

rm ~/.config/yarn/global/yarn.lock
cd ~/.config/yarn/global
yarn cache clean
yarn global add markdown-spellcheck