PNPM Scripts¶
There are several pnpm scripts in the framework's package.json
to help start your local development or build the assets to deploy to production.
There are four primary commands: start
, build
, start-launch
and build-launch
. Each one of these commands accepts an optional argument of [env]
. The env
argument points to a defined property within the theme-settings.json
file. For example running pnpm run start live
would start the local proxy pointing to the live
environment.
For more information on how to use these scripts, see the Customize CSS & JS > Local Development Workflow section.
We use the Genesis CLI package to handle these arguments and flags.
Recommended Reading¶
Common Shortcuts¶
These are the two most common tasks that you may need to run:
start
¶
- Command:
$ pnpm run start [env]
- Description: This script will trigger the Customize CSS & JS > Local Development Workflow for webpack to compile your initial set of files, watch for updated SCSS & JS files, and setup the browser-sync local-server.
build
¶
- Command:
$ pnpm run build [env]
- Description: This script will run the production build command which is useful for generating the files that you can deploy to a miva-store
@mvps-genesis/cli (previously ./scripts/run.js
)¶
Allows a developer to run any pnpm script with a specified environment through the command line.
The CLI package will be installed locally and accessed with pnpm exec
. However, you can also install the genesis CLI globally by running this in your terminal:
pnpm add -g @mvps-genesis/cli
Once the CLI is installed you can run commands with the genesis
binary. Run genesis help
for more info.
For example if you want to run the build:webpack
script within the staging environment:
genesis run build:webpack staging
Monorepo Scripts¶
Common in Development¶
bootstrap
¶
- Command:
$ pnpm run bootstrap
- Description: Recursively install all of the packages' dependencies.
- Uses: Run this after switching between branches
start
¶
- Command:
$ pnpm run start
- Description: Shortcut for starting the BrowserSync local development server
- Uses: Use anytime your terminal is at the root of the repo and you want to quickly start the dev server
One-time Use¶
init
¶
- Command:
$ pnpm run init
- Description: A one-time repo-setup command to enable LFS, setup the githooks, install dependencies
- Uses: Run this after cloning the repo for the first time.
init:lfs
¶
- Command:
$ pnpm run init:lfs
- Description: A one-time repo-setup command to enable LFS
- Uses: Run this if you haven't run
pnpm run init
or if you haven't enabled LFS
init:theme
¶
- Command:
$ pnpm run init:theme
- Description: Installs dependencies and runs the build command
init:githooks
¶
- Command:
$ pnpm run init:githooks
- Description: A one-time repo-setup command to enable the repos githooks.
- Uses: Run this if you haven't run
pnpm run init
or if you haven't installed the githooks on your repo
init:husky
¶
- Command:
$ pnpm run init:husky
- Description: Installs husky on the repo and ensures that the repo's git-hooks have been registered as well. It should only need to be ran once after cloning the repo.
- Further Reading: See "Husky Git Hooks" below for more information
postinstall
¶
This command typically does not need to be run manually because it is automatically called after a $ pnpm install
.
Publishing¶
pre-release
¶
Publishes all packages within the workspace that do not have a version on the npm registry. Sets the npm tag to alpha
.
release
¶
Publishes all packages within the workspace that do not have a version on the npm registry. Uses the default tag (latest
).
Automatically Run¶
preinstall
¶
- Command:
$ pnpm run preinstall
- Description: This ensures that you are using
pnpm
to install decencies; instead ofnpm
oryarn
- Uses: This is automatically called by pnpm when you
pnpm install/add
, so you do not need to run it.
version
(Packages Only)¶
Recursively updates other packages within the workspace that depend on it.
publish
(Packages Only)¶
Create and push a git tag with the following format:
$npm_package_name@$npm_package_version
For example:
@mvps-genesis/[email protected]
Linting¶
lint
¶
- Command:
$ pnpm run lint
- Description: Runs all of the various
lint:[ext]
pnpm commands to lint each of the different linters (stylelint, eslint, etc.) - Uses: Use this to manually lint the entire repo. Will likely be used in CI/CD pipelines to ensure lint errors are resolved before deployments.
lint:js
¶
- Command:
$ pnpm run lint:js
- Description: Runs
eslint
on all of the JS files in the repo (excludingnode_modules
and the files listed in the.eslintignore
file. - Uses: Use to ensure the code-base's JavaScript adheres to our code-style. Also, you can automatically fix files in bulk by passing the
--fix
command toeslint
like so$ pnpm run lint:js -- --fix
lint:scss
¶
- Command:
$ pnpm run lint:scss
- Description: Runs
stylelint
on all of the SCSS files in the repo (excludingnode_modules
and the files listed in the.stylelintignore
file. - Uses: Use to ensure the code-base's CSS & SCSS adheres to our code-style. Also, you can automatically fix files in bulk by passing the
--fix
command tostylelint
like so$ pnpm run lint:scss -- --fix
Husky Git Hooks¶
Husky & Lint-Staged, and jira-prepare-commit-msg have been added to automate several tasks through git hooks.
Husky¶
Husky is a described as, "Modern native Git hooks made easy". Which is exactly what we're using it for. Tying into and extending git's hook system so we can perform the lint-staged & jira-prepare-commit-msg commands.
Lint-Staged¶
Lint Staged's tagline is, "Run linters against staged git files and don't let 💩 slip into your code base!".
It is responsible for triggering lint commands targeted to the files that are staged by git so that it can run faster & prevent you having to correct issues you did not author. The lint-staged
portion of the package.json
will check for git's staged files that match the pattern in the key section (ex. *.js
& .scss
), then it will execute the command and stop the git commit if errors are found.
jira-prepare-commit-msg¶
jira-prepare-commit-msg is a husky command to add JIRA ticket ID into the commit message if it is missed.