DEV Community: Bart Wijnants

Testing an Apollo GraphQL server using apollo-server-testing, Jest and msw

Bart Wijnants — Sat, 14 Nov 2020 21:23:09 +0000

How do you easily test an Apollo GraphQL server that gets data from external api’s?

Continue reading on Medium »

Agnita: Authentication for Create React App using AWS Cognito

Bart Wijnants — Mon, 13 Apr 2020 19:37:40 +0000

The Agnita project is a proof of concept implementation using Amazon Cognito and create-react-app.

Continue reading on Medium »

I'm building a blog about building a blog

Bart Wijnants — Mon, 23 Dec 2019 10:54:15 +0000

Some time ago I noticed there was money to be made on Medium. I joined the Medium Partner Program and moved some of my posts behind the metered paywall. Time to become a millionaire.

I quickly wrote a new blogpost and shared it here and on Reddit. This received some backlash as someone commented "Too bad you care about money more than sharing it. ¯(ツ)/¯". That hurt, but it was also kinda true.

This sparked a thought in my head. I can just create my own blog. Maybe add some ads. And still become a millionaire. I can just blog about building a blog. Easy does it.

I already have 3 posts:

Gatsby From Scratch: Create a very simple Gatsby site from scratch without using a starter.
Fill The Head The Rest Will Follow: Add a header and manifest to a Gatsby site using some basic GraphQL.
Tailwind: Use the Tailwind CSS framework in a Gatsby site.

And a ton of notes waiting to be converted to posts.

Check it out!

Getting started with TypeScript for Node

Bart Wijnants — Sat, 23 Nov 2019 15:23:10 +0000

A step by step guide

Continue reading on Medium »

retyst: A React Typescript Starter

Bart Wijnants — Sun, 23 Sep 2018 11:19:56 +0000

check retyst out on GitHub

scripts

npm install
npm start
npm run build:dev
npm run build:prod
npm run detach

about

This is a simple starter repo to quickly get a React Typescript project going.

The dev dependencies include Typescript and Webpack with ts-loader, html-webpack-plugin, webpack-cli and webpack-dev-server.

The dependencies are react, react-dom and styles-components.

I will try to keep this repo up to date whenever I use it (and that might be never).

usage

You can test this repo by executing npm install followed by npm start and then browse to http://localhost:8080/.

You can use the npm run build:dev and npm run build:prod to check out the generated bundles.

The npm run detach script removes all connections to retyst and the .git folder so you can start your own project.

license

This repo is licensed under the MIT License.

Continuous deployment to Firebase hosting using Travis CI

Bart Wijnants — Wed, 15 Aug 2018 10:11:18 +0000

Intro

Last night I had another multi million dollar web app idea. So of course first thing I do in the morning is start to work on my idea. Got to earn those dollars.

The first thing I need is some place on the internet where my customers can start handing me over their money. I want to move fast, so each time I change something I want to see the results immediately.

Enablers

Firebase is a platform by Google that provides hosting with minimal effort and for free. Travis is a hosted continuous integration solution that will allow me to deploy my changes to Firebase. GitHub is the place where I’ll be storing my precious code.

To build this stuff I installed Node.js and Docker on my laptop. I didn’t really need Docker but I did not feel like installing Ruby.

Let’s go to work

Go to Firebase and create a new project.
Create a new repository on GitHub.
Clone the repository locally.
Create a minimal index.html.

mkdir public
touch public/index.html

Connect GitHub repository to Firebase project using the Firebase tools. Don’t overwrite index.html when initializing.

npm install -g firebase-tools
firebase login
firebase init

Generate a Firebase CI token (and keep it handy).

firebase login:ci

Go to Travis and activate the GitHub repository.
Encrypt the Firebase CI token using Travis CLI.

# only run the docker command if you don't have and don't want to install Ruby
docker run -it --rm ruby:latest bash
gem install travis
travis encrypt "1/firebase_CI_token" -r githubusername/reponame

Create a .travis.yml file to deploy to Firebase after every push to GitHub.

language: node_js
node_js:
  - "node"
script:
  -
deploy:
  provider: firebase
  token:
    secure: "encrypted_firebase_CI_token"

Commit and push the changes to GitHub.
Watch Travis build and deploy.
Check Firebase Hosting to see the deployment history.
Go to the Firebase Hosting domain for the project to see the website.

Conclusion

I just spent half a day on writing a guide on continuously deploying a website to Firebase using Travis CI and I didn’t start working on my multi million dollar idea.

Find the code on GitHub.

See the website here.

Incrementally migrate your webpack project to TypeScript

Bart Wijnants — Fri, 04 Aug 2017 06:48:33 +0000

TL;DR

If you want to migrate to TypeScript but don’t want to migrate all your code at the same time you can configure webpack to bundle both TypeScript and JavaScript code.

You can find a demo project here.

How to?

To add TypeScript to a webpack project you can follow these steps:

Install the needed dev-dependencies:

npm install --save-dev @types/jest awesome-typescript-loader typescript @types/lodash

Create a tsconfig.json file to specify that you want to transpile to ES6:

{
  "compilerOptions": {
    "target": "es6"
  }
}

Add awesome-typescript-loader to your webpack config file and load your TypeScript first through the TypeScript transpiler and then through Babel:

module: {
  rules: [
    { test: /\.jsx?$/, exclude: /node_modules/, use: "babel-loader" },
    { 
      test: /\.tsx?$/, 
      exclude: /node_modules/, 
      use: ["babel-loader", "awesome-typescript-loader" }
  ]
}

To stop Babel from transforming ES6 module syntax to commonjs you need to update the .babelrc file:

{
  "presets": [["es2015", { "modules": false }], "react"],
  "plugins": ["transform-class-properties"]
}

Now comes the tricky part: keeping the Jest tests running.

Some extra configuration is necessary to tell Jest to transpile TypeScript and to have the normal JavaScript run through Babel-Jest.

In your package.json add the following Jest config:

"jest": {
  "moduleFileExtensions": ["ts", "tsx", "js", "jsx"],
  "transform": {
    "^.+\\.(ts|tsx)$": "<rootDir>/preprocessor.js",
    "^.+\\.(js|jsx)$": "babel-jest"
  },
  "testRegex": "(/ __tests__ /.*|\\.(test|spec))\\.(ts|tsx|js|jsx)$"
}

Create a preprocessor.js file to transpile TypeScript tests:

const tsc = require("typescript");

module.exports = {
  process(src, path) {
    if (path.endsWith(".ts") || path.endsWith(".tsx")) {
      return tsc.transpile(src, {}, path, []);
    }
    return src;
  }
};

In .babelrc you need to add a separate configuration for the test environment to play nice with Jest:

{
  "presets": [["es2015", { "modules": false }], "react"],
  "plugins": ["transform-class-properties"],
  "env": {
    "test": {
      "presets": ["es2015", "react"],
      "plugins": ["transform-class-properties"]
    }
  }
}

Now you should be able to start migrating files one by one to TypeScript without breaking tests or builds.

Continuous deployment of a webpack app to multiple environments using Travic CI

Bart Wijnants — Thu, 03 Aug 2017 09:29:52 +0000

TL;DR

I set up continuous deployment of a webpack app with tests in Jest hosted on Firebase using GitHub and Travis CI. Deploys to the DEV environment are done on every commit to master. Deploys to the PROD environment are done on every tag to master.

Check out the code here.

How to?

In code I use a default value:

var text = __CONFIG__ || “default”;

That value can be overridden in a webpack config file:

plugins: [
  new webpack.DefinePlugin({ 
    __CONFIG__ : JSON.stringify("override")
  })
]

In my .firebaserc file I defined multiple Firebase projects:

{
  "projects": {
    "prod": "prod-multi-webpack-travis",
    "dev": "dev-multi-webpack-travis"
  }
}

This allows me to setup ci for each project by executing the following commands:

firebase use dev
firebase login:ci
travis encrypt "1/xxx"

In the .travis.yml file I defined multiple deploys:

deploy:
  - provider: firebase
    project: dev
    token:
      secure: "encrypted stuff"
    skip_cleanup: true
    on:
      branch: "master"
  - provider: firebase
    project: prod
    token:
      secure: "encrypted stuff"
    skip_cleanup: true
    on:
      tags: true

Now I can also use the environment variables that Travis defines in my webpack config file:

plugins: [
  new webpack.DefinePlugin({ 
    __CONFIG__ : JSON.stringify(
      process.env.TRAVIS_TAG ? "override on tag" : "override"
    )
  })
]

If I do a push to GitHub the dev deploy is triggered and if I update the version then the dev and prod deploy are triggered:

npm version patch
git push --follow-tags

To get Jest tests working on files where the environment files are used I added some Jest configuration to my package.json file:

"jest": {
  "globals": {
    " __CONFIG__": null
  }
}

Conclusion

It took me way too long to get this working so I decided to write this blog post. This setup makes it very easy to have different configurations for each environment.

A downside is that the code needs to be bundled again every time you change environment.

Using Prettier and husky to make your commits safe.

Bart Wijnants — Wed, 14 Jun 2017 20:00:54 +0000

Whether you work in a team or by yourself, having consistently formatted code is important for readability and maintainability.

Tl;dr

Use Prettier to automatically format your JavaScript and use husky and lint-staged to add a precommit script that runs Prettier and your tests when you commit.

Check out the full code:

bartw/pretty_husky

ESLint vs JavaScript Standard Style vs Prettier

For JavaScript there are solutions like ESLintthat can check if your code is consistent. But ESLintrequires a lot of configuration and while it can fix some things by itself, it often requires manual intervention when you screw up.

Then there is JavaScript Standard Style. This module is the complete opposite of ESLint. It requires no configuration and can also fix some of your code by itself. But having no configuration, it’s very opinionated.

And now there is also Prettier. The difference between Prettier and other lint tools is that Prettier doesn’t check your code. It just takes your code as input and spits out formatted code as output. Like JavaScript Standard Style, Prettier is opinionated but you have some options to customize the format. Because Prettier doesn’t check your code but parses it, everything will be fixed automatically. Sounds like the best of both worlds.

Hello Prettier

The best way to see the greatness of Prettier is to try it out.

Fire up your terminal and start typing:

mkdir pretty_husky
cd pretty_husky
npm init -y
npm install --save-dev prettier
mkdir src
touch ./src/foo.test.js
code .

Now you can write some poorly formatted code in foo.test.js:

test('this needs to be prettier.', () => {
expect(4).toBe(4)
})

And add a script package.json to run Prettier:

"scripts": {
    "pretty": "prettier--write --tab-width 4 \"src/**/*.js\""
}

Now you can run Prettier from your terminal:

npm run pretty

And you can see that the contents of foo.test.js have changed to:

test("this needs to be prettier.", () => {
    expect(4).toBe(4);
});

What about that husky?

Prettier makes your code look pretty but what if you forget to run it before you check in?

You could run Prettier as a step during continuous integration but then you have to check your code in again if there are changes. It would be much easier if you made sure that no “ugly files can be pushed or committed.

This is where husky comes in. Husky makes creating git hooks easy. Git hooks are scripts that git executes before or after and event. If husky runs Prettier for us then “ugly files can never be committed. But it’s not that easy. Husky can run Prettier but the changed files won’t be added to our commit.

This problem can be solved by lint-staged. Lint-staged can run a lint tool, like Prettier, and immediately add them to the staged files.

Hook me up!

If you haven’t created a git repository yet now is the time, your hooks won’t work without a repository:

git init
touch .gitignore

Add “node_modules to the .gitignore file to avoid checking in too much:

node_modules

Go back to your terminal and install husky for the hooks, lint-staged for adding the formatted files to the staged files and Jest to run some tests:

npm install --save-dev husky lint-staged jest

Create some scripts to hook everything up in your package.json file:

"scripts": {
    "test": "jest",
    "pretty": "prettier --write --tab-width 4 \"src/**/*.js\"",
    "precommit": "npm run pretty && npm test"
},
"lint-staged": {
    "*.js": [
        "npm run pretty",
        "git add"
    ]
}

Make some ugly and failing tests in foo.test.js:

test('ugly', () => {
expect(4).toBe(4)
})

test('failing', () => {
    expect(4).toBe(5);
});

Now try to commit:

git add .
git commit -m"will this work?"

The script ran and the test failed, foo.test.js got updated:

test("ugly", () => {
    expect(4).toBe(4);
});

test("failing", () => {
    expect(4).toBe(5);
});

And husky stopped the commit:

> husky - pre-commit hook failed (add --no-verify to bypass)
> husky - to debug, use 'npm run precommit'

If you fix the test and try again the commit should work.

Conclusion

Prettier, husky and lint-staged can improve your workflow by formatting your JavaScript files and running some scripts before every commit.

Check out the full code on GitHub.

Running tests for .NET and Node.js on Travis CI

Bart Wijnants — Sun, 11 Jun 2017 07:05:10 +0000

Introduction

Together with a colleague I started working on Partei. Like a lot of projects this consists of a web api that does some stuff and a front-end.

To make things easy we decided to serve our front-end from the same server that serves our api and to keep them in the same git repository. We opted for ASP.NET Core in the back-end and React in the front.

We set up the projects and configured Travis CI to run our tests and publish to Heroku.

Initially we only had .NET tests and Travis ran them without a problem. But then we introduced Jest tests for the front-end. Travis CI has Node.js installed by default on the .NET environment so thing should go smooth.

But things didn’t go smooth. Apparently the default version of Node.js is 4 and our project is written using Node.js 8.

Time to figure out a solution for this.

Solution

I created a repo with a .NET Core test project and an npm project both with a simple test.

bartw/dotnetcore_node_travis

On Travis CI, Node Version Manager (nvm) is available. In my .travis.yml file I used nvm to install Node.js 8 and use this version to run our tests.

Now both the .NET tests and the Node.js tests are running together.