DEV Community: Julien Ripouteau

Validate-env plugin for Vite

Julien Ripouteau — Sun, 02 Oct 2022 07:36:20 +0000

Have you ever restarted a CI several times in a row because you forgot to add some environment variables?

Or spent an hour debugging an issue only to realize that it was just one of your environment variables that was undefined? Or maybe this variable was filled in but badly formatted?

This is the problem that vite-plugin-validate-env tries to solve.

https://github.com/Julien-R44/vite-plugin-validate-env

Introduction

So, this plugin for Vite allows you to validate your environment variables at build time with 0 runtime overhead.

🪛 Totally type-safe. Types are inferred from your schema definition.
✅ Support multiple validation librairies ( Zod, and @poppinss/validator-lite )
👉 Parsing, validation, transformation
🎉 Custom rules and error messages

And it's as simple as that :



// vite.config.ts
import { defineConfig } from "vite";
import { ValidateEnv } from "@julr/vite-plugin-validate-env";

export default defineConfig({
  plugins: [
    ValidateEnv({
      VITE_MY_VAR: Schema.string()
    }),
  ],
})

Now, before launching your dev server with pnpm dev, or launching a build with pnpm build, the plugin will validate your environment variables. If something is wrong, the process will stop immediately and warn you.

See fail-fast

Here is the output we will get directly in our terminal when we try to launch or build our application :

Transforming variables

Also, let's imagine the following case: you want to expose a variable VITE_AUTH_API_URL in order to use it to call an API. However, you absolutely need a trailing slash at the end of this environment variable. Here's how it can be done :



import { defineConfig } from '@julr/vite-plugin-validate-env'
import { z } from 'zod'

export default defineConfig({
  validator: 'zod',
  schema: {
    VITE_AUTH_API_URL: z
      .string()
      .transform((value) => value.endsWith('/') ? value : `${value}/`),
  },
})

Note two things here:

The schema is validated using Zod, which can be useful if you already use this library. But it would also be possible with the other validator.

The schema is defined here in a dedicated file env.ts. Separating the schema from vite.config.ts is much cleaner.

And that's it. If one of your colleagues forgets the trailing slash at the end of this environment variable, it will be automatically added.

Type safe `import.meta.env`

If you are doing typescript, you may know that you can have intellisense on the import.meta.env object by manually adding your variables, as explained here in the documentation of vite :

https://vitejs.dev/guide/env-and-mode.html#intellisense-for-typescript

With vite-plugin-validate-env, you kill two birds with one stone. Defining your schema will allow you to super easily augment your import.meta.env object like this :



type ImportMetaEnvAugmented = import('@julr/vite-plugin-validate-env')
  .ImportMetaEnvAugmented<typeof import('../env').default>

interface ImportMetaEnv extends ImportMetaEnvAugmented {
  // Now import.meta.env is totally type-safe and based on your `env.ts` schema definition
}

Example :

I hope you will find this plugin useful, and if you have any feedback, please let me know ! I am also open to any PRs, if you want to contribute to the project.

You can find the project here on GitHub with much more information about the different features in the README : https://github.com/Julien-R44/vite-plugin-validate-env

Please show some 💖 and star the project if you like it, it will help me a lot to get more visibility on the project.

Introducing Factorify - A model factory library for Node.js

Julien Ripouteau — Sun, 25 Sep 2022 17:20:43 +0000

Have you ever written tests, in which the first 15-20 lines of each test are dedicated to just setting up the database state by using multiple models?

That's the problem Factorify is trying to solve

If you have already worked with Adonis.js, or Laravel, the concept of model factory must be very familiar to you. The idea here is exactly the same, Factorify is totally inspired by that.

I built Factorify because I quickly realized that Model Factories was a tool that I was really missing to do my tests while I was working on a different stack ( The current stack I have to work on is Hasura / AWS Lambda ).

Most of the time using Factorify is relevant when you are working on a stack without ORM, or if your ORM does not offer an equivalent feature. But any good ORM must offer a more or less similar system :

For example MikroORM, which is the ORM for the cool kids right now, offers factories: https://mikro-orm.io/docs/seeding#entity-factories

Prisma ORM doesn't seem to have a builtin solution, but there are third party plugins for : https://github.com/echobind/prisma-factory

Lucid, which is the ORM of Adonis.js, also have model factories : https://docs.adonisjs.com/guides/models/factories

etc.

Factorify is very, very simple to use. I will skip the database configuration step for keeping the post short, but you can find more information on the documentation website : https://factorify.julr.dev/

The first step is to simply define factors for each of your models. Here we will work on a database that has three models, users, and posts, and comments.
A user can have several posts, and a post can have several comments.

We start by defining the factories, with the relationships they have between them:

export const CommentFactory = defineFactory('comment', ({ faker }) => ({
  content: faker.lorem.paragraph(),
}))
  .build()

export const PostFactory = defineFactory<>('post', ({ faker }) => ({
  title: faker.lorem.sentence(),
}))
  // 👇 We define a relationship between the post and the comment model
  .hasMany('comments', () => CommentFactory)
  .build()

export const UserFactory = defineFactory<any>('user', ({ faker }) => ({
  id: faker.datatype.number(),
  name: faker.name.fullName(),
  role: 'user'
}))
  .state('admin', () => ({ role: 'admin' }))
  // 👇 We define a relationship between the user and the post model
  .hasMany('posts', () => PostFactory)
  .build()

And that's it! We are ready to write tests that are clean.
In any of our tests, we can now use the factories to create the database state we need.

import { UserFactory } from '../factories.js'

test('My test ', () => {
  // 👇 We create 3 users, each with 2 posts, and each post with 3 comments
  const user = await UserFactory
    .with('posts', 2, posts => posts.with('comments', 3))
    .createMany(3)

  // 👇 We can also create a single admin user by applying the previously defined state
  const admin = await UserFactory.apply('admin')
    .with('posts', 4)
    .create()

  // Now you can focus on testing your business logic, without having to write
  // 15 lines of code to create the database state you need 🎉
})

And there you go. This makes test writing much easier and cleaner !

Factorify hides a lot of other nice features, like :

Stubbing, which allows you not to persist anything in the database and just return the model to memory. Useful for testing an API : you just generate the model and store it in a variable, you send it to your API with supertest or whatever :

test('Should insert user', () => {
  // 👇 Calling `make` or `makeMany` will generate the model in memory, without persisting it in the database
  const user = await UserFactory.make()

  request(app).post('/users').send(user).expect(200)
})

Attributes overriding, which allows you to override the attributes of a model, without having to redefine the whole factory :

// 👇 We override the name attribute of the user
const user = await UserFactory.merge({ name: 'Julien' }).create()

And some other features that you can find on the documentation website : https://factorify.julr.dev/

I hope you will find Factorify useful, and if you have any feedback, please let me know ! I am also open to any PRs, if you want to contribute to the project.