ENV variables and building packages seperatly

[Jarrodsz]

Im trying to build my packages seperatly for better debugging but have a little problem getting the .env variables to work defined in the root of the monorepro. Tried this for 1 hour to no avail. What would be the correct way to use .env variables in packages?

my latest attempt is to load inside encryption.sever.ts

import bcrypt from "bcryptjs";
import crypto from "crypto";

import dotenv from 'dotenv';
dotenv.config();

const ENCRYPTION_KEY = crypto.scryptSync(
    process.env.ENCRYPTION_SECRET,
    "salt",
    32
);

the process.env.ENCRYPTION_SECRET is set in the root of the mono repro inside an .env file:

ENCRYPTION_SECRET="12345"

turbo.json is the same as yours almost with:

 "globalDependencies": [".env"]

I tried to

    "build": "source .env && turbo run build",

I run:

pnpm build

Then it complains about the value not set

@core/auth:build: src/utils/encryption.server.ts(8,5): error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'BinaryLike'.

If i hardcode the variable inside the encryption.server.ts it seems to work so somehow it does not load from the .env in the base.

Does anyone how I could resolve this?

On a side note. each application in /apps/myapp1/ would have its own .env but for more easy package building some dummy data in the root .env would be more convient. since else i have to specify manually the .env for each project and they basically hold the same values for encryption for remix-auth and stripe.

[PhilDL]

Hi, there are multiple solutions that I will explain, choose one or a combination of multiple solutions:

Quick fix to turbo.json to avoid problems later

Not reflected in this monorepo but used in others, you should update your turbo.json globalDependencies like so:

"globalDependencies": ["**/.env"],

Symbolic link between env files

Like in the current monorepo, /packages/database.env is a symbolic link to the root env, created by doing:

ln -s ./.env ./packages/database/.env

This works but is not the best, you usually don't commit .env files so you will have to document (I also forgot to say it in my own documentation) for your teammate or your future self that after copying .env.example to .env they should also create symlinks.

Be also careful during CI / Github actions / Dockerfile, to do all the COPY necessary.

Making extensive use of dotenv-cli

Install it in your package:

pnpm add -D dotenv-cli --filter @core/auth

Then update your package.json file to create utility

"scripts": {
    // other stuff
    "with-env": "dotenv -e ../../.env --"
}

Then update your scripts to use that, for example to generate prisma schema:

"db:migrate:dev": "pnpm with-env prisma migrate dev",
"with-env": "dotenv -e ../../.env --"

That way you specifically call for the root .env

My own opinion (take it with a grain of salt)

I personally think .env should not be expected from packages, the app should be the one responsible for consuming the packages. If instantiation values are necessary the consumer should be responsible for the choice "should I take this value from an .env file, a yaml, json file, etc" and not be enforced by secondary packages.

Packages should expose a clear API where, if a configuration is needed, it should be an input at instantiation and not an internal, wherever that value comes from.

[Jarrodsz]

Thank you Phil.

I see where you go with this, actually both symlink and providing the .env file "with-env" seems like not really fancy.
Also your point regarding the external dependency of a external .env file that could be in the root of monorepro or an application root ( i actually use ENV memory values in production ) is not that fancy either.

So you basically mean that I should somehow factor the use of the .env in my encryption.server.ts out which would be the best since there is no external dependency. I also think this makes it more rock solid but have to investigate how I could refactor the code.

Im buildin remix apps with the mono repro and normally the .ENV values get loaded from the .env in development just for testing and by memory variables provided to a docker container on runtime in production.

Do you have a suggestion how I could refactor this problem to not use .env ?

[PhilDL]

Sorry, I didn't mean "don't use .env" generally, I meant that .env should only be really present at the remix app level. The different remix apps should be responsible for their .env and composing their dependencies.

For example, you showed me this error

@core/auth:build: src/utils/encryption.server.ts(8,5): error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'BinaryLike'.

Could you refactor that so it's more generic and could run in pure TypeScript or Next or any other framework? Remix should be responsible for importing that package into a .server.ts that compose the encryption and feed it a .env value.
And for example, if tomorrow you will use NextJS, instead of having a .server.ts suffix you will import in a file with the use server directive to specify the runtime.

On the other way if you know that you will only do remix apps and want to create a pure remix package it's also okay! But try to refactor it in a way that let the Remix app choose how to create that ENCRYPTION_KEY.

We could imagine from your @core/auth package, something like that:

import bcrypt from "bcryptjs";
import crypto from "crypto";

const composeEncryption = (secret:string) => {

  const ENCRYPTION_KEY = crypto.scryptSync(secret, "salt", 32);

  const doStuff = async (data:unknown) => {
    // I am doing stuff
  }

  return {
    doStuff,
    ENCRYPTION_KEY
  }
}

export { composeEncryption }

And in your Remix app inside a encryption.server.ts:

import { composeEncryption } from "@core/auth";

const { doStuff, ENCRYPTION_KEY } = composeEncryption(process.env.ENCRYPTION_SECRET);
// ...

These are vague ideas, I don't have all your requirements 😁 but maybe something in that vein, for that case when you don't want to symlink .env files.

For example, if you make a package about stripe, it's gonna be even more complicated having to deal with APP_URL / CALLBACK_ENDPOINT, STRIPE_KEY that are usually comfortably in the .env. This way of doing things will make you have to create a big config object that will give you all the public methods OR have you pass the STRIPE_KEY as an argument to every exported function from your package, complexifying your implementation. That's tradeoffs only you can know if you are willing to take! 😅