Time Saving BASH Functions for Yarn and NPM Projects.

You just booted a create-app or cloned a starter from github. You will need to gain an understanding of the structure and dependencies to be productive.

This guide will examine several scenarios where BASH utilities are helpful during project discovery or routine development. Readers should have some knowledge of BASH, NPM or Yarn.

What are the dependencies and where are they declared in this project?

Lets start with the project’s primary dependencies in package.json. It really helps to understand the declared dependencies here because this is the root of your dependency tree.

jq '.["dependencies"]' package.json
# if you do not have jq, you could use python:
python -c 'import sys, json; print(json.load(sys.stdin)["dependencies"])' < package.json 

This will print something like:

{
  "prism-theme-vars": "^0.2.2",
  "vue": "^3.0.11",
  "vue-router": "^4.0.8"
}

To check devDependencies, you should use:

jq '.["devDependencies"]' package.json

To print the scripts configured in package.json you would run:

jq '.["scripts"]' package.json

While you may be asking why you would not just open the package.json file and read its contents. If you are working with multiple documents at once, it is cumbersome to have to look in package.json frequently. Create some shell functions to output these quickly.

Print the dependency tree.

If you are experienced with NPM or Yarn, you are probably flipping your griddle right now because you know that NPM and Yarn have more robust way to list dependencies.They even allow you to pass a --depth {n} option for a tree view.

npm ls --depth 1
# or with yarn
yarn ls --depth 1

This will print something like the following:

dependencies:
@vueuse/core 4.11.2
├── @vueuse/shared 4.11.2
└── vue-demi 0.9.1
@vueuse/head 0.5.1
└── vue 3.1.1 peer
vue 3.1.1
├── @vue/compiler-dom 3.1.1
├── ...
└── @vue/shared 3.1.1

Knowing where dependencies are referenced and configured.

This is all great, but what if you need to know where a dependency is configured or referenced in the code? Using find and grep together, we can pipe a list of files to grep for searching. We do not want to search within the node_modules folder and we want to keep our search to just .yaml, .json, .md, and .js files.

find . \! -path "*node_modules*" \
  \( -name "*.yaml" -or -name "*.json" -or -name "*.md" -or -name "*.js" \) -print0 \ 
  | xargs -0 grep -l "some-package"

The pattern ! -path "x" excludes a path from being passed to grep. You may also wish to exclude your build and .git folders as well.

The above snippet prints a list, which is nice. How about printing the actual lines where the match is found? All you have to do is change the last line of the previous command to:

  | xargs -0 grep -C 1 -n "some-package"

The option -C 1 gives a little more context by instructing grep to include one line above and below the match. The -n option outputs the line numbers where the match was found.

Understanding what types of files are in this project.

To get a list of file extensions, use find and sed:

find . -type f \! -path "*node_modules*" \! -path "*git*" \ 
  | sed -n 's/..*\.//p' | sort -us

To get a sorted count of all of these files use:

find . -type f \! -path "*node_modules*" \! -path "*git*" \ 
  | sed -n 's/..*\.//p' | sort | uniq -c | sort -nr

This will print something like:

  14 vue
  12 yml
  10 js
   9 md
   5 css
   4 json
   2 html
   1 npmrc
   1 eslintrc

Why is dependency X required?

Often you will wish to know why some package not listed in your package.json file is required. This is likely because your dependencies have dependencies. This is how you check out what those are:

npm ls "lodash"
# or with yarn
yarn why "lodash"

The above command displays the following:

eslint-plugin-vue 7.11.1
└─┬ vue-eslint-parser 7.6.0
  └── lodash 4.17.21

Are any packages outdated?

Do not forget to routinely run the auditing feature to detect if any packages are vulnerable.

npm audit
# or with yarn
yarn audit

The latest versions of NPM and Yarn allow you to specify production environments so that you can determine your level of action.

npm audit --production
# or with yarn
yarn npm audit --environment production

That is all for now.

Hopefully you can incorporate some of these into your workflow. I have found that they are huge time savers. Also, command line utilities are often faster than searching in your editor.