Using environment variables

When dealing with secrets, it is handy to use environment settings. You can easily access them in the Node.js library using process.env['whatever']. Some frameworks accept only environment variables that start with a specific prefix to avoid human errors (see an example in Basic Features: Environment Variables | Next.js).

Add environment variables to your project

First, create a template file that is committed to GitHub, so be careful not to add any secrets.

Create file .env.template and add only the keys; for example, to keep AWS secrets, you might see something like:

AWS_KME_ACCESS_KEY_ID=  
AWS_KME_SECRET_ACCESS_KEY=

The env template file is essential for developers to know which variables the library expects.

In the .gitignore file, add the following:

.env
**/.env

Create file .env and copy the content from the .env.template file. This time does write the secrets.

Commit your changes and make sure the .env file is ignored.

Loading the variables from the .env file

The reason to have this file is to let you set secrets locally on your machine for development purposes and later use the same environment variables in GitHub actions or other CI/CD services with production values.

But a script in your project will not automatically load the variables from this file. To do that, you will use dotenv - npm by running

node -r dotenv/config {path_to_js_file} {variable - optional}

For example:

node -r dotenv/config node_modules/.bin/obsidian-album

Passing environment settings to scripts in GitHub actions

When using GitHub actions, you store the environment variables as secrets. Although they are accessible in the workflow file, they will not be exposed automatically to any script triggered by the workflow.

Continuing my example from above, let's say you want to run obsidian-album with environment variables AWS_KME_SECRET_ACCESS_KEY and AWS_KME_ACCESS_KEY_ID:

- name: run script with some environment variables 
  run: |  
    npx obsidian-album 
  env:  
    AWS_KME_SECRET_ACCESS_KEY: ${{ secrets.AWS_KME_SECRET_ACCESS_KEY }}  
    AWS_KME_ACCESS_KEY_ID: ${{ secrets.AWS_KME_ACCESS_KEY_ID }}

Using the playground folder

When having many configurations for a library, consider having a safe place that will include temporary files needed during development and shouldn't be committed to GitHub. I usually do the following:

In .gitignore file, add the following:

playground

In folder playground, I then create the configuration file if supported by the library or a bash script that I can use; for example, I have a bash file roma.sh:

node ../dist/packages/cli/src/cli create output.pdf --vault '****' \  
      --subFolder life-journey --filterBy '(life journey)' --filterFrom '2022-11-06' --filterTo '2022-11-11' \  
      --title 'Rome 2022' --coverImage '*****' --verbose

Later I can execute it from the terminal with ./roma.sh.

Sometimes I'm getting permissions denied on my computer. To bypass it, I either run it with sudo or run instead chmod 777 ../dist/packages/cli/src/cli.