DEV Community: Douglas Pinheiro Goulart

Creating a complete NodeJS test environment with Vitest, PostgreSQL and Prisma

Douglas Pinheiro Goulart — Sun, 23 Apr 2023 17:48:55 +0000

Introduction

In the world of software development, testing is a critical aspect of ensuring the quality and reliability of a product. Unit tests and end-to-end tests are two important types of tests that developers use to identify and fix bugs before releasing their code into production. Unit tests focus on testing individual functions and modules in isolation, while end-to-end tests simulate user behavior and test how the system works as a whole, including its interaction with external systems and dependencies. In this article, we will explore how to create a complete Node.js test environment using Postgres and Prisma. By setting up a robust testing infrastructure, we can catch bugs early and ensure that our code is performant and reliable in production. We will walk through the steps required to set up a test environment. With the right tools and mindset, testing can become an integral part of your development process, helping you to create high-quality software that meets the needs of your users.

Paving the way

Let's configure the necessary tools.

Prisma

So, the first thing we have to do is install the required dependencies. I'm going to use NPM as the package manager here, but feel free to use your preferred tool.

To start, we need to install the Prisma CLI in our project by running:

npm i prisma -D

This way we can execute commands like npx prisma migrate dev and others alike in our project. Since we only use the Prisma CLI in our development environment, we can install it as a development dependency as recommended by the Prisma documentation.

Now we can start Prisma by using:

npx prisma init

This will create a new prisma/schema.prisma file. This is a declarative configuration file where we can define our database schema using the Prisma Schema Language.

💡 Tip for VSCode users: as an extra step, you can install the Prisma extension and also add this to your VSCode configuration:

"[prisma]": {
  "editor.formatOnSave": true
},

This will make sure that your schema.prisma file is always auto formatted every time you save.

By default, Prisma already sets the database provider as postgresql, so your schema.prisma file should look something like this:

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

Feel free to define your models there.

Next up, we can execute the Prisma generate command:

npx prisma generate

This will read our schema.prisma file and generate the Prisma client based on the data models defined in it.

The next thing we need to do is, of course, configure our database.

By default, Prisma already generates a .env file with an example PostgreSQL database URL. It should look something like this:

# Environment variables declared in this file are automatically made available to Prisma.
# See the documentation for more detail: https://pris.ly/d/prisma-schema#accessing-environment-variables-from-the-schema

# Prisma supports the native connection string format for PostgreSQL, MySQL, SQLite, SQL Server, MongoDB and CockroachDB.
# See the documentation for all the connection string options: https://pris.ly/d/connection-strings

DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"

PostgreSQL

To set up our database, I'm going to use Docker here. If you already have PostgreSQL installed in your machine, feel free to use it. If you want to use Docker just like me, you can follow the installation tutorial here.

With Docker installed, we can pull the PostgreSQL image by running:

docker pull bitnami/postgresql

And then create our Docker container by running

docker run --name node-test-env-pg -e POSTGRESQL_USERNAME=docker -e POSTGRESQL_PASSWORD=docker -e POSTGRESQL_DATABASE=node-test-env -p 5432:5432 -d bitnami/postgresql

This will create a container with the name "node-test-env-pg", username "docker", password "docker" and database with the name "node-test-env" on port 5432 in detached mode by making use of the bitnami/postgresql image we just pulled.

Now we can change the DATABASE_URL inside the .env file created by Prisma with the new connection URL:

DATABASE_URL="postgresql://docker:docker@localhost:5432/node-test-env?schema=public"

The username changed from "johndoe" to "docker", the password changed from "randompassword" to "docker" as well, and the database name changed from "mydb" to "node-test-env", which are the parameters we specified when creating our Docker container.

To test if everything is working properly, we can now execute the Prisma migration command inside our project:

npx prisma migrate dev

Choose a name for your first migration and confirm. This will create and run the database migrations for you. If you are not yet familiar with database migrations, you can check out this article.

TypeScript (optional)

We can begin installing TypeScript by adding typescript, node types, tsx and tsup to our project:

npm i typescript @types/node tsx tsup -D

The tsx package will be responsible for running our application in the development environment, and the tsup package will be necessary to bundle our application.

We can now initialize TypeScript by using:

npx tsc --init

This will create our tsconfig.json file.

In the tsconfig file, we can change the target to es2020 (as es2020 is 100% supported since Node.js 14.0.0).

{
  "compilerOptions": {
    ...
    "target": "es2020",
    ...
  }
}

To avoid the relative import hell, we can also uncomment the baseUrl line and set custom paths in this configuration file:

{
  "compilerOptions": {
    ...
    "baseUrl": "./",
    "paths": {
      "@/*": ["./src/*"]
    },
    ...
  }
}

This way, instead of having to import stuff like this:

import { someModule } from '../../../../../some-file';

We can import stuff using absolute imports like this:

import { someModule } from '@/custom/path/to/some-file';

Much better, right?

To avoid always having to import things like "test" and "expect" from Vitest, we can also add vitest/globals to our tsconfig configuration file:

{
  "compilerOptions": {
    ...
    "types": [
      "vitest/globals"
    ],
    ...
  }
}

And in our vitest.config.ts file we specify test globals as true:

export default defineConfig({
  ...
  test: {
    ...
    globals: true,
    ...
  },
  ...
});

And now you can remove vitest imports from your test files. Our sample.spec.ts would be like this:

test('should execute', () => {
  expect(1 + 1).toBe(2);
});

We can also take a moment and add the required scripts to run our project. Add them in your package.json file:

...
"scripts": {
  ...
  "start:dev": "tsx watch src/index.ts", // change the path to match your project initialization file
  "start": "node build/server.js",
  "build": "tsup src --out-dir build",
  ...
}
...

Vitest

Ok, now is the time to configure our test runner.

We can install Vitest normally with:

npm i vitest -D

If you are using TypeScript with custom paths, you can also install vite-tsconfig-paths.

npm i vite-tsconfig-paths -D

What we need to do now is create our Vitest config file. Create a vitest.config.ts (vitest.config.js if you are not using TS) in the root directory of your project with the following content:

import tsconfigPaths from 'vite-tsconfig-paths'; // only if you are using custom tsconfig paths
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {},
  plugins: [tsconfigPaths()],  // only if you are using custom tsconfig paths
});

If you run npx vitest run now, all your tests should be running. Nice!

If you don't have any tests yet, you can begin by creating a sample.spec.(ts|js) file that just tests if 1+1 is equal to 2:

import { test, expect } from 'vitest';

test('should execute', () => {
  expect(1 + 1).toBe(2);
});

To avoid manually having to run vitest with npx every time, we can create a new npm script inside the project global package.json. Let's add the following scripts there:

...
"scripts": {
  "test": "vitest run",
  "test:watch": "vitest"
},
...

The test script will run the tests only once, while the test:watch script will keep watching for file changes and re-run the tests accordingly.

We can also add a script to run tests with the test coverage report. Let's add it to our package.json:

...
"scripts": {
  ...
  "test:coverage": "vitest run --coverage"
},
...

If you run this script, it will ask you to install the @vitest/coverage-c8 package to your project. Install it and run it again with npm run test:coverage and you should see your tests running and a new coverage folder in your project. Open the index.html inside the coverage folder and you should be able to see details about the test coverage of your project. Also, this folder can be safely added to your .gitignore, since it will be generated every time you run the test:coverage command.

Unit and E2E tests

As mentioned in the Introduction, unit tests and E2E tests are both really important aspects of software development. They ensure that everything is working fine and allow us to find bugs before users do.

If you are executing unit tests, it's completely fine to have in-memory databases. Since unit tests are designed to test individual units of code in isolation, an in-memory database can provide a quick and easy way to test database interactions without relying on a real database. This can speed up test execution time and simplify the testing process. However, in-memory databases are not suitable for end-to-end testing because they do not accurately reflect the behavior of a real database. End-to-end tests are designed to test the entire system from start to finish, including its interaction with external systems and dependencies, such as a real database. In-memory databases do not provide the same level of complexity and reliability as a real database, and may not accurately reflect the behavior of a production database. For this reason, we are going to configure a entirely new test environment to run our end-to-end tests with Vitest.

Creating Prisma Test Environment

Inside our root prisma folder, we will start by creating a new vitest-environment-prisma directory.

Since Vitest environments need to be a package, we can now open this directory with our terminal and run npm init -y there to create a new one.

The next thing we'll need to do is create a prisma-test-environment.ts file alongside our newly created package.json.

After creating the prisma-test-environment.ts file, now we need to change the entry point of our prisma/vitest-environment-prisma/package.json file to be the prisma-test-environment file we just created:

{
  ...
  "main": "prisma-test-environment.ts",
  ...
}

As stated in the documentation, a custom Prisma test environment looks something like this:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  setup() {
    // custom setup
    return {
      teardown() {
        // called after all tests with this env have been run
      }
    }
  }
}

This is exactly the structure we will use in our prisma-test-environment.ts file:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'prisma',
  setup() {
    // custom setup
    return {
      teardown() {
        // called after all tests with this env have been run
      }
    }
  }
}

The only difference is that the name of the environment needs to be set to "prisma".

Since we need a new, clean database for each test suite, we will need to do a few things. The approach we are going to use here is:

For each test suite, we:

Initialize Prisma Client;
Generate a new database schema with a random name (PostgreSQL uses "public" as default);
Update the DATABASE_URL defined in our .env file;
Execute Prisma migrations;

At the end of every test suite, we:

Drop the newly created schema;
Disconnect from Prisma;

Let's start by initializing the Prisma client:

import type { Environment } from 'vitest';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export default <Environment>{
  ...
}

Now, in our setup function, we need to generate our random schema name:

import type { Environment } from 'vitest';
import { PrismaClient } from '@prisma/client';
import { randomUUID } from 'node:crypto';

const prisma = new PrismaClient();

export default <Environment>{
  name: 'prisma',
  async setup() {
    const schema = randomUUID();

    return {
      async teardown() {
        ...
      },
    }
  },
}

I'm using node:crypto to generate a random uuid here, but feel free to use any tool that generates a random, unique string.

If you remember correctly, our DATABASE_URL follows a structure that looks something like this:

DATABASE_URL="postgresql://docker:docker@localhost:5432/node-test-env?schema=public"

The only thing we are going to do is replace the "public" schema with the newly generated schema name.

Let's create a function to regenerate our DATABASE_URL with the new schema:

import 'dotenv/config';
import { randomUUID } from 'node:crypto';
import { Environment } from 'vitest';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

function generateDatabaseURL(schema: string) {
  if (!process.env.DATABASE_URL) {
    throw new Error('Please provide a DATABASE_URL environment variable.');
  }

  const url = new URL(process.env.DATABASE_URL);

  url.searchParams.set('schema', schema);

  return url.toString();
}

export default <Environment>{
  name: 'prisma',
  async setup() {
    const schema = randomUUID();
    const databaseURL = generateDatabaseURL(schema);

    process.env.DATABASE_URL = databaseURL;

    return {
      async teardown() {
        ...
      },
    }
  },
}

Also, make sure to install the dotenv package:

npm i dotenv

Now we just need to execute our migrations with Prisma:

import 'dotenv/config';
import { randomUUID } from 'node:crypto';
import { execSync } from 'node:child_process';
import { Environment } from 'vitest';
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient()

function generateDatabaseURL(schema: string) {
  ...
}

export default <Environment>{
  name: 'prisma',
  async setup() {
    const schema = randomUUID();
    const databaseURL = generateDatabaseURL(schema);

    process.env.DATABASE_URL = databaseURL;

    execSync('npx prisma migrate deploy');

    return {
      async teardown() {
        ...
      },
    }
  },
}

Here, we are using npx prisma migrate deploy instead of npx prisma migrate dev because we don't want to check for any changes in our schema.prisma file (therefore, creating a new migration). We just want to execute our current migrations and that's exactly what npx prisma migrate deploy does.

Right. Now, the only thing left is our teardown function. This will be executed at the end of every test suite. As described in the steps listed above, we need to DROP our schema and disconnect from Prisma. So this is exactly what we are going to do:

...
export default <Environment>{
  name: 'prisma',
  async setup() {
    const schema = randomUUID();

    ...

    return {
      async teardown() {
        await prisma.$executeRawUnsafe(
          `DROP SCHEMA IF EXISTS "${schema}" CASCADE`,
        );
        await prisma.$disconnect();
      },
    }
  },
}

This drops the schema if it exists and disconnects from the Prisma client.

Our Prisma test environment file is done!

Telling Vitest when to execute unit or e2e tests

Currently, if we run the previously created test or test:watch scripts, all tests will run, including unit and E2E tests. This is not good because, as we saw earlier, unit and end-to-end tests are completely different type of tests. For this reason, we are now going to create two different Vitest configurations: one for unit tests, and one for e2e tests.

To do this, we can begin by creating two files alongside our vitest.config.ts:

vitest.e2e.config.ts and vitest.unit.config.ts.

Inside our vitest.unit.config.ts, we can tell Vitest that we want to exclude any file containing the extension *.e2e-spec.*:

import { configDefaults, defineConfig, mergeConfig } from 'vitest/config';
import vitestConfig from './vitest.config';

export default mergeConfig(
  vitestConfig,
  defineConfig({
    test: {
      exclude: [
        ...configDefaults.exclude,
        '**/*.e2e-{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}',
      ],
    },
  }),
);

Here, we merge our old vitest.config.ts file with our common configuration (like the tsconfigPaths plugin). This way we don't have to define everything twice.

In our test object, we tell Vitest that we don't to run any test files that are named like *.e2e-{test|spec}.*. This will ensure that no end-to-end tests are run when using this configuration file.

Inside our vitest.e2e.config.ts, we will do something similar:

import { defineConfig, mergeConfig } from 'vitest/config';
import vitestConfig from './vitest.config';

export default mergeConfig(
  vitestConfig,
  defineConfig({
    test: {
      include: ['**/*.e2e-{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
      environmentMatchGlobs: [['src/**', 'prisma']],
    },
  }),
);

Just like the previous file, we merged the common Vitest config. In this file, instead of excluding the "*.e2e-{test|spec}.*" files, we include them. This way we only execute specific e2e test files.

Also, we added a new environmentMatchGlobs object that tells Vitest that, for every file inside our src folder, we want to use our previously created prisma test environment.

The only thing left now is to create our test scripts.

In the project package.json, we are going to modify our current test scripts that we added earlier, as well as add new test scripts for e2e tests.

First of all, let's specify the config file for our already created test commands with the -c flag:

"scripts": {
  ...
  "test": "vitest run -c vitest.unit.config.ts",
  "test:watch": "vitest -c vitest.unit.config.ts",
  ...
}

This will tell Vitest that we want to use the vitest.unit.config.ts file we just created as the configuration file.

Now, we can add the new commands for executing end-to-end tests:

"scripts": {
  ...
  "test:e2e": "vitest run -c vitest.e2e.config.ts",
  "test:e2e:watch": "vitest -c vitest.e2e.config.ts",
  ...
}

This is the same thing, but instead of using the vitest.unit.config.ts as our configuration files, we are going to use our vitest.e2e.config.ts file. This is going to ensure that only e2e tests are run when this script is executed.

Linking test environment

Since every Vitest custom test environment always needs to be a package, we need to link our project to the prisma test environment we created, otherwise it won't be recognized and our end-to-end tests won't run properly. To do this, we can add some scripts to run before executing our end-to-end tests. In our package.json, we will add the following scripts:

"scripts": {
  ...
  "test:create-prisma-environment": "npm link ./prisma/vitest-environment-prisma",
  "test:install-prisma-environment": "npm link vitest-environment-prisma",
  "pretest:e2e": "run-s test:create-prisma-environment test:install-prisma-environment",
  ...
}

The test:create-prisma-environment command will create the Prisma environment. Here, we use npm link which creates a symbolic link between the package and the location where it would normally be installed;
The test:install-prisma-environment command will install the Prisma environment in our project;
The pretest:e2e command will always run before we run npm run test:e2e. This command runs both the test:create-prisma-environment and the test:install-prisma-environment. It uses run-s from the npm-run-all package, so make sure to install it with:

npm i npm-run-all -D

From now on, every time you create a file with "e2e-spec" or "e2e-test" in its name and run npm run test:e2e or npm run test:e2e:watch, it will be included in the "tests to run" by Vitest and will execute, making sure everything is working in your project.

Conclusion

In this article, we manage to configure an entire Node.js environment with TypeScript, PostgreSQL, Prisma and Vitest. We also learned about the about unit and end-to-end tests and how they differ.

By now, you should have a project that allows you to ensure the quality and reliability of your code before shipping to users.

Feel free to suggest improvements and/or corrections 🙂.

The complete code of this article can be found here.

Avoid TypeScript errors in your project by using the TypeScript compiler

Douglas Pinheiro Goulart — Sat, 28 May 2022 00:12:45 +0000

Introduction

Let's suppose you have a large TypeScript project with a lot of features. In this project, you are tasked of refactoring one of the most important component in your entire application: the user registration form (assuming you are using React), which is an extremely detailed and vitally important feature in your application.

Alright, you have done it, you refactored everything and... now there are a lot of TypeScript errors because the types of the props that this component receives are different from all of the usages of this component in your app. How do you find all your usages easily?

Sure you can use the good old Cmd+Shift+F or Ctrl+Shift+F, but there's another easier and better way to do this.

To fix this, we can use tsc. The good thing about tsc is that you can use it to maintain the integrity of your project and keep it free from errors.

First of all, what is `tsc`?

Assuming you are new to TypeScript, tsc is The TypeScript Compiler. It is a tool responsible for turning your TypeScript (which is a superset of JS) code into plain JavaScript. Since, as of today, browsers only understand JavaScript code, tsc makes your TS code readable by browsers.

Alright, how do we use it?

Assuming you already have a TypeScript project with a tsconfig.json file and also a package.json file, add a scripts property if there isn't one yet.

...
"scripts": {
  ...
},
...

It'll be here where we will add our typecheck command:

...
"scripts": {
  "typecheck": "tsc --project tsconfig.json --noEmit",
},
...

Alright, now let's go over this command:

First, we execute the tsc compiler
We pass the --project flag to explicitly tell the compiler that we want to typecheck the entire project using our specified config file, which is the tsconfig.json.
Lastly, we pass the --noEmit flag to say that we do not want to output the compiled JS files into our project. If we don't set this flag and, for example, we have a TS file located at src/utils/boolToText.ts, there would be created a file called src/utils/boolToText.js, which is the JavaScript version of the src/utils/boolToText.ts file outputed by the compiler.

If there are no TS errors in your code, you should see something like this:

If some error(s) was found, you should see something like this:

Now you can open the files with errors and fix them :)

Additional configuration you can use

There are also some additional configuration I like to do to make sure my project is safe and sound, free from any errors.

Run on pre-commit with husky and lint-staged

One thing I like to do is to configure my typecheck command with lint-staged and husky on pre-commit along with my tests and eslint verification.

So, my .lintstagedrc.json file looks something like this:

{
  "*.{ts,tsx}": [
    "eslint 'src/**' --fix",
    "npm run test:staged"
  ]
}

And my .husky/pre-commit file looks like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install lint-staged
npm run typecheck

This way, every time I commit something, it will do lint check, run my tests and typecheck my entire project.

💡 Notice: The reason why I'm not executing my npm run typecheck inside lint-staged is that, since lint-staged only runs staged files and passes the current file being checked by argument to the command being executed, we can't have a reference to the tsconfig.json file (with the --project flag) and a source file to check in the same command. If you do, you'll get a TS5042: Option 'project' cannot be mixed with source files on a command line. error. Passing npm run typecheck in the husky pre-commit hook separated from lint-staged will typecheck the entire project, and not just the staged files. It's not perfect, but it works! There's an issue in the official TypeScript repository about this, in case you want to take a look.

If you don't have lint-staged and husky installed yet, you can refer to their official documentation:

Create a task on VSCode to watch for errors

Another nice thing you can do is create a VSCode task to watch for errors in your project as you code.

To do this:

Open the command palette (Cmd+Shift+P) or (Ctrl+Shift+P).
Select Tasks: Configure Task.
Select tsc: watch - tsconfig.json
Make sure the "noEmit": true option is set in the "compilerOptions" section in your tsconfig.json so that tsc do not output js files all over your project.

Now, there will be created a .vscode/tasks.json in your project with the following content:

{
    "version": "2.0.0",
    "tasks": [
    {
      "type": "typescript",
      "tsconfig": "tsconfig.json",
      "option": "watch",
      "problemMatcher": [
        "$tsc-watch"
      ],
      "group": "build",
      "label": "tsc: watch - tsconfig.json"
    }
  ]
}

Set a custom label if your want to.

{
    ...
    "tasks": [
    {
      ...
      "label": "Watch for TypeScript errors"
    }
  ]
}

Now, you can open your command palette again and select Tasks: Run Task
Select your Watch for TypeScript errors (or the name you chose) task.

This will open a new terminal window with the execution of your task and it will keep watching for errors.

Congratulations. You are done creating your VSCode task :)

Conclusion

Congratulations! Now you have a error-proof project, especially if you configured husky and lint-staged too.

As always, improvements and/or corrections are welcome 😀.

Have fun coding!

Deploying your Laravel + MySQL application on Heroku

Douglas Pinheiro Goulart — Fri, 30 Apr 2021 22:18:41 +0000

Introduction

So, you've just built your beautiful Laravel application, it has authentication, localization, tests and all the fancy features that could possibly impress the recruiter and land you a job. However, it's only working on your machine. How do we solve this?

In this post, we’ll be looking into hosting a Laravel application (with a MySQL or MariaDB database included) on Heroku for free.

Deploying

💡 Notice: Replace items within brackets ([]) with your desired information.

Creating Laravel application

If you don't have a Laravel app yet, the first thing we got to do is create a brand new one. To do this, first you need to have Composer installed on your machine. After installing composer you can run the following command to install the Laravel installer:

composer global require laravel/installer

And then you can create a new Laravel app:

laravel new [brand-new-app]

For more information about Laravel installation, check the Laravel Installation guide. It’s worth a read before following the instructions in this article.

Initializing `git`

To deploy to Heroku we'll be using Git. If you don't know how to use this, I recommend you watch the Git and GitHub Crash Course on freeCodeCamp. It's a very important tool for developers and you should know it.

Anyways, the first thing you gotta do is enter your project folder using the terminal and initialize a git repository:

git init

And then adding all the files and making a commit

git add .
git commit -m "Initial commit"

Alright, now your git repository is set.

Using the Heroku CLI

We'll use the Heroku CLI to deploy our app. You can find the installation guide here.

After you've installed the Heroku CLI, create a Heroku free account and run heroku login in your terminal. Follow the instructions and after you've been successfully logged in, you can create your Heroku application (change brand-new-app to your desired app name):

heroku create [brand-new-app]

Now you need to generate the APP_KEY required by Laravel. You can do this by using the heroku config:set APP_KEY=$(php artisan --no-ansi key:generate --show) command.

Creating a Procfile

By default, Heroku will launch an Apache web server together with PHP to serve applications from the root directory of the project.

However, our application’s document root is the public/ subdirectory, so we need to create a Procfile that configures the correct document root. We can do this by manually creating a Procfile file or using the terminal:

echo "web: vendor/bin/heroku-php-apache2 public/" > Procfile

Add the untracked files and commit your changes:

git add .
git commit -m "Procfile for Heroku"

Pushing to Heroku

Now you should be able to push your app to Heroku:

git push heroku master

To view your app, access https://[brand-new-app].herokuapp.com or click the Open app button located in the Heroku dashboard (https://dashboard.heroku.com/apps/[brand-new-app])

Avoiding Mixed Content error

If you use the asset() helper function a lot, you'll probably notice that your hosted app isn't loading some assets files and is showing a Mixed Content error in the console.

To fix this, open your applications' AppServiceProvider at [brand-new-app]/app/Provider/AppServiceProvider.php and, in the boot() method, add:

if (config('app.env') === 'production') {
    \URL::forceScheme('https');
}

And now create a APP_ENV variable with a production value using the Heroku CLI or on your app's settings (https://dashboard.heroku.com/apps/[brand-new-app]/settings > Config Vars > Reveal Config Vars).

heroku config:set APP_ENV="production"

Commit and push your new changes to Heroku

git commit -am "Adding URL::forceScheme('https') in production environments"

Now your project should load properly without errors

If the error persist, check if there are no links using HTTP instead of HTTPS.

Setting environment variables

The next thing we need to do is set our .env variables in Heroku. We've already set the APP_ENV and APP_KEY variables, let's set the remaining ones. Again, you can do this by using the Heroku CLI or on your app's settings (https://dashboard.heroku.com/apps/[brand-new-app]/settings > Config Vars > Reveal Config Vars).

You can keep the database information (DB_CONNECTION, DB_DATABASE, DB_USERNAME, etc) the same as the local configuration for know. We'll take care of that later.

Adding and configuring database

Now we have to add a database to our project.

Go to your application dashboard and click on resources (https://dashboard.heroku.com/apps/[brand-new-app]/resources). In the "Add-ons" input, type MySQL and choose ClearDB MySQL. Select the "Ignite - Free" plan and click on "Submit Order Form".

Make sure you assigned your credit card to your Heroku account. If you didn't add it yet, click on your profile photo (top right corner) > Account settings > Billing > Add credit card. Don't worry, you won't be charged unless you choose a paid plan. As soon as you've added your card, repeat the step above.

As soon as you've added the ClearDB MySQL add-on, go to your terminal and type heroku config | grep CLEARDB_DATABASE_URL

It should display something like this:

CLEARDB_DATABASE_URL:  mysql://uuuuuuuuuuuuuu:pppppppp@hh-hhhh-hhhh-hh.cleardb.com/heroku_ddddddddddddddd?reconnect=true

Everything after the @ symbol until the / is the DB_HOST (hh-hhhh-hhhh-hh.cleardb.com). Everything after / until ? is DB_DATABASE (heroku_ddddddddddddddd). The string after the // until : is the DB_USERNAME (uuuuuuuuuuuuuu). The string between : and @ is the DB_PASSWORD (pppppppp).

Don't show, tell or publish these credentials anywhere. These are your database information. That's why I censored it. In your case it should have real numbers and letters.

Now it's time to change your production database environment variables with the real ones provided by ClearDB. Go to your app settings (https://dashboard.heroku.com/apps/[brand-new-app]/settings), click "Reveal Config Vars" and change the database variables. It should be like this:

key	value
DB_HOST	hh-hhhh-hhhh-hh.cleardb.com
DB_DATABASE	heroku_ddddddddddddddd
DB_USERNAME	uuuuuuuuuuuuuu
DB_PASSWORD	pppppppp

Migrating database tables

Now it's time to run our migrations and create our database tables.

In your terminal, type heroku run php artisan migrate:fresh. It will ask you if you really want to run this command, type yes.

After running this command, there is a high chance that it will return this error:

It happens because, by default, Laravel uses the utf8mb4 character set. If the server is running a version of MySQL older than the 5.7.7 release or MariaDB older than the 10.2.2 release, you may need to manually configure the default string length generated by migrations.

Learn more at: https://laravel.com/docs/8.x/migrations#index-lengths-mysql-mariadb.

To fix this, add the code below to the boot() method located in your app/Providers/AppServiceProvider.php

Schema::defaultStringLength(191);

Don't forget to import Schema at the top of the file:

use Illuminate\Support\Facades\Schema;

Your AppServiceProvider should be like this at this point:

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Schema;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        if (config('app.env') === 'production') {
            \URL::forceScheme('https');
        }

        Schema::defaultStringLength(191);
    }
}

Commit your changes and push to Heroku again

git commit -am "Setting defaultStringLength to 191"
git push heroku master

Run the migrations again with heroku run php artisan migrate:fresh and it should work.

Seeding the database

Let's learn how you can seed your database in case you need to.

In your terminal, type heroku run php artisan db:seed. It will also ask you if you really want to run this command, type yes.

💡 Notice: Heroku increments tables by 10, for example id's would appear like this: 1, 11, 21, 31. Beware when using user IDs for reference in Seeds or Factories.

When you run this command, it might tell you that the Class 'Faker\Factory' was not found. It happens because faker is required as a dev dependency. To fix this, simply open your composer.json file and move "fzaninotto/faker": "^1.9.1", from require-dev to require.

And then run composer update.

Commit your changes and push to Heroku one more time

git commit -am "Moving fzaninotto/faker from require-dev to require in composer.json"
git push heroku master

Seed the database again with heroku run php artisan db:seed and it should work.

[BONUS] Storing uploaded files

In case you are working with file uploads in your Laravel application, there's one caveat you should be aware of: Heroku uses ephemeral filesystem. That means that any changes to the filesystem whilst the dyno is running only last until that dyno is shut down or restarted. Each dyno boots with a clean copy of the filesystem from the most recent deploy. In addition, under normal operations dynos will restart every day in a process known as "Cycling".

When this happens, your image or any other uploaded file will be completely deleted from your application and users will see nothing but the image alt text.

Knowing this, it's recommended that you use a dedicated file storage service such as AWS S3.

You can learn more about this approach that Heroku uses here and here.

Conclusion

Congratulations! Now you have your Laravel application up and running. Now you can add it to your portfolio and show your work to people.

Heroku free plan has some limitations and maybe your app stop working in some days of the month (it usually goes back online when a new month starts). If you are feeling the need to upgrade, do it.

Improvements and/or corrections are welcome 😀.

Como fazer efeito de skeleton loading com ReactJS

Douglas Pinheiro Goulart — Sat, 28 Mar 2020 18:11:11 +0000

Introdução

Quando acessamos uma página na web, o que esperamos é uma resposta instantânea ou o mais rápido possível. Porém, com as abordagens tradicionais que utilizam spinners, ou até mesmo que não mostram nenhuma resposta na tela enquanto os dados são carregados, isto geralmente não ocorre. Muitas vezes ficamos esperando, recarregamos a página, e não temos nenhum feedback da aplicação até que os dados sejam carregados.
Para resolver este problema, foi criado o skeleton loading. O skeleton loading é uma abordagem que visa melhorar a experiência do usuário exibindo elementos de carregamento que são similares ao conteúdo real que vai ser apresentado quando todos os dados carregarem.

Implementação no ReactJS

Agora que já entendemos o conceito e o motivo de utilizar skeleton loading, vamos para a prática.

Para implementar esta funcionalidade em uma aplicação ReactJS, vamos usar o pacote react-loading-skeleton.

Instalação

Com o NPM, use o comando abaixo para instalar o pacote (dentro da pasta do projeto):

npm install react-loading-skeleton

Já se estiver usando o yarn, use o seguinte comando:

yarn add react-loading-skeleton

Estado de loading e pegando dados da API

Para checar se os dados da nossa aplicação estão sendo carregados ou não, vamos criar um estado chamado loading e setar o mesmo true por padrão. Também vamos criar um estado data para armazenar nossos dados

import React, { useEffect, useState } from 'react';

function Component() {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(true);

  return <h1>Skeleton Loading</h1>
}

export default Component;

Agora, utilizando o hook useEffect, vamos fazer a chamada a API, e, logo após isso, setar o loading como false

import React, { useEffect, useState } from 'react';

import api from '../../../services/api';

function Component() {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const timer = setTimeout(() => {
      api.get('data').then(response => {
        setData(response.data);
      });

      setLoading(false);
    }, 3000);

    return () => clearTimeout(timer);
  }, []);

  return <h1>Skeleton Loading</h1>
}

export default Component;

Como estamos em ambiente de desenvolvimento, usamos a função setTimeout para que possamos ver as mudanças. É importante que você remova em produção.

Criando componente skeleton

Para fazer o skeleton, vamos criar um componente separado. É neste componente que importaremos o pacote que instalamos anteriormente

import React from 'react';
import Skeleton from "react-loading-skeleton";

function ComponentSkeleton() {
  ...
}

export default ComponentSkeleton;

Agora vamos usar o componente <Skeleton /> para montar nosso layout

import React from 'react';
import Skeleton from "react-loading-skeleton";

import './styles.css';

function ComponentSkeleton() {
    <div className="skeleton-container">
      <div className="skeleton-title">
        <Skeleton height={28} width={300} />
      </div>

      <ul>
        {Array(8)
          .fill()
          .map((item, index) => (
            <li key={index}>
              <div className="item-group">
                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>

                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>
              </div>

              <div className="item-group">
                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>

                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>
              </div>

              <div className="item-group">
                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>

                <div className="skeleton-item">
                  <Skeleton height={20} width={`100%`} />
                </div>
              </div>
            </li>
        ))}
      </ul>
    </div>
}

export default ComponentSkeleton;

Com as propriedades width e height ajustamos a largura e a altura. Você também pode utilizar outras propriedades como count, para a repetição automática, ou duration, para setar a duração da animação. Caso queira saber mais, confira a documentação do pacote no GitHub.

Caso queira alterar coisas como o espaçamento desses elementos, você pode coloca-los dentro de divs e estilizar no CSS.

Checando se os dados já foram carregados ou não

Voltando ao nosso componente principal, precisamos verificar se os dados já foram carregados ou não. Para isso vamos usar o estado loading que criamos anteriormente

import React, { useEffect, useState } from 'react';
import ComponentSkeleton from '../ComponentSkeleton';

import api from '../../../services/api';

function Component() {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const timer = setTimeout(() => {
      api.get('data').then(response => {
        setData(response.data);
      });

      setLoading(false);
    }, 3000);

    return () => clearTimeout(timer);
  }, []);

  return (
    <div className="container">
      {loading && <IncidentSkeleton />}
      {!loading &&
        <>
          <h1>Skeleton Loading</h1>

          <ul>
            {data.map(item => (
              <li key={item.id}>
                <strong>TÍTULO:</strong>
                <p>{item.title}</p>  

                <strong>DESCRIÇÃO:</strong>
                <p>{item.description}</p>  

                <strong>VALOR:</strong>
                <p>{item.value}</p>
              </li>
            ))}
          </ul>
        </>
      }
    </div>
  );
}

export default Component;

Abaixo do container estamos dizendo que, se o loading for true, mostre o skeleton. Logo abaixo estamos dizendo o contrário, se o loading for false, mostre os dados vindos da API.

Alternativas

Além do react-loading-skeleton, também temos outras alternativas como o react-content-loader e o react-loading-screen. Caso queira saber as vantagens e desvantagens de cada um, acesse este artigo.

Conclusão

Esta é uma solução que melhora muito a experiência do usuário, reduzindo a frustração que as telas de loading causam, além de ter uma implementação extremamente simples. Neste artigo usamos um pacote para facilitar o processo, mas você também pode fazer tudo com CSS se quiser.

Caso queira, vocẽ pode acessar o código completo da aplicação no GitHub.

DEV Community: Douglas Pinheiro Goulart

Creating a complete NodeJS test environment with Vitest, PostgreSQL and Prisma

Introduction

Paving the way

Prisma

PostgreSQL

TypeScript (optional)

Vitest

Unit and E2E tests

Creating Prisma Test Environment

Telling Vitest when to execute unit or e2e tests

Linking test environment

Conclusion

Avoid TypeScript errors in your project by using the TypeScript compiler

Introduction

First of all, what is tsc?

Alright, how do we use it?

Additional configuration you can use

Run on pre-commit with husky and lint-staged

Create a task on VSCode to watch for errors

Conclusion

Further reading

Deploying your Laravel + MySQL application on Heroku

Introduction

Deploying

Creating Laravel application

Initializing git

Using the Heroku CLI

Creating a Procfile

Pushing to Heroku

Avoiding Mixed Content error

Setting environment variables

Adding and configuring database

Migrating database tables

Seeding the database

[BONUS] Storing uploaded files

Conclusion

Further reading

Como fazer efeito de skeleton loading com ReactJS

Introdução

Implementação no ReactJS

Instalação

Estado de loading e pegando dados da API

Criando componente skeleton

Checando se os dados já foram carregados ou não

Alternativas

Conclusão

First of all, what is `tsc`?

Initializing `git`