katt/envsafe

🔒 Makes sure you don't accidentally deploy apps with missing or invalid environment variables.

envsafe's Issues

withTRPC and VERCEL_URL

The documentation for next.js SSR for trpc requires us to set the following in _app.tsx:

const url = process.env.VERCEL_URL
      ? `https://${process.env.VERCEL_URL}/api/trpc`
      : 'http://localhost:3000/api/trpc';

I tried using envsafe with this with devDefault. This failed when performing a yarn build on my local machine (and was the only variable to do so). It works fine in yarn dev (presumably because VERCEL_URL is set by nextjs) but doesn't work when building. What's the recommended solution for yarn build?

In nextjs, is passing any server only env variables to envsafe exposes it to client?

Hey, thanks for the awesome package. Since I have no expertise in this area I would like to ask a question. Is passing any server only env variables in nextjs (without prefixing it with NEXT_PUBLIC) to envsafe exposes it to client? Is there any security concerns here?

question: can this be used for libraries?

Essentially the title. Should I be able to use this in a library so that if the consumer doesn't supply a required env var it will prompt them so (for instance in a next app). In my experimentation, it seems to work for one library, but when I add another to the mix it's unable to find a defined env variable... 🤔

tetest

test

Originally posted by @KATT in https://github.com/KATT/envsafe/discussions/27

Add Option to Disable Fallback Mechanism in Next.js envsafe

Problem

I'd like to highlight an issue that arises when passing environment variables to envsafe in Next.js, using the code from the Example as a reference.

In Next.js applications, we use the input option to inline environment variable values during the build process and pass them to envsafe.

  NEXT_PUBLIC_NO_DEFAULT: str({
    input: process.env.NEXT_PUBLIC_NO_DEFAULT,
  }),

However, if there happens to be a typo in the specified environment variable name, envsafe is unable to identify the error.　For instance, consider the following scenario where the PABLIC segment is incorrect (while PUBLIC is the correct one):

  NEXT_PUBLIC_NO_DEFAULT: str({
    input: process.env.NEXT_PABLIC_NO_DEFAULT,
  }),

The reason behind this behavior is that envsafe relies on a fallback mechanism where it references the environment variable using NEXT_PUBLIC_NO_DEFAULT when the input value is empty.

Unfortunately, this fallback mechanism is ineffective for Next.js client-side applications. It causes delays in issue detection and creates unnecessary obstacles in such scenarios.

Proposal

I propose introducing an option that allows users to disable the fallback mechanism at their discretion. By adding, for instance, the inputOnly option, we give users the ability to control this behavior.

export const browserEnv = envsafe({
  NEXT_PUBLIC_NO_DEFAULT: str({
    input: process.env.NEXT_PUBLIC_NO_DEFAULT,
    // Only individual items can be targeted
    // inputOnly: true
  }),
}, {
   // By setting this flag to `true`, only the input value will be referenced, and the value in process.env will be ignored.
  inputOnly: true
})

Utilizing this feature empowers Next.js application builders to detect typographical errors in environment variables during the build process, treating them as build errors rather than runtime issues.

Pull Request

• #144

---

I believe that the majority of cases where input is used are with Next.js.
Therefore, I thought it would be a good idea to make it the default behavior to disable fallback when using input.
However, I am not certain that anyone would find it harmful, so I opted to add the flag so as not to break the existing behavior.

Map choices array to union types

This is a great QoL addition that I've been using a lot from ts-dotenv, but the implementation details of this library is so different that another approach is better.
In ts-dotenv you specify an array that are cast as const as so:

LOG_LEVEL: {
    type: [
      'fatal' as const,
      'error' as const,
      'warn' as const,
      'info' as const,
      'debug' as const,
      'trace' as const
    ],
    default: 'info'
  },

which gives you the type

'fatal' | 'error' | 'warn' | 'info' | 'debug' | 'trace'

It would be amazing if we could conditionally do this for choices. Here is an example of how it can be done:

function stringLiteralArray<T extends string>(a: T[]) {
    return a;
}

const fruits = stringLiteralArray(["Apple", "Orange", "Pear"]);
type Fruits = typeof fruits[number]

Support generics for JSON variables

Today the json validator returns unknown type, is there a reason for that?

Can we add support to generics to cover that gap?

AS-IS

const env = envsafe({
  CREDENTIALS: json(),
});

env.CREDENTIALS  // unknown 

TO-BE

const env = envsafe({
    CREDENTIALS: json<AppCredentials>(),
})

env.CREDENTIALS // AppCredentials

Not working on nextjs

I am trying to setup envsafe in a NextJs project, but it is not working.
The values are printed in console, on the server side also client side but still the validation is showing them as missing.

Printed value in NextJs dev server:

Browser console is showing the value and also the validation error.

The validation code:

import { str, envsafe, url, bool } from 'envsafe';

console.log('NEXT_PUBLIC_RUM_KEY' + process.env.NEXT_PUBLIC_RUM_KEY);

export const env = envsafe({
  NEXT_PUBLIC_RUM_KEY: str(),
});

Node version: v16.18.1
NextJs version: 13.2.4