DEV Community: OliverOdo

Markdown link checker: Oh My Github Action #1

OliverOdo — Fri, 27 Jan 2023 17:13:12 +0000

Github Action changed the game!
Continuous Integration has never been so exciting.

In this series, I just want to share my findings about the different Github Action I’m using to empower different projects.

About the Github Action?

Name: 404-links
Description: The only Github Action that will open pull request review when a broken link has been found in one of your markdown documentation.
Marketplace: https://github.com/marketplace/actions/404-links
Maintainer: Olivierodo

What I love about It?

Compared to other Markdown link checker, I love the different feature of 404-links:

Allow whitelist by url or by file
Enforce https links
Share a simple summary
Create Pull Request review using PR comments

How do I use it?

Currently I’m maintaining the RestQA that has more than 50+ markdowns file. Most of the files has external links (github pr, 3rd party tools), Now i’m happy to know that each link will be check regularly checked in order to provide a good experience while reading our documentation.

How can you use it?

If your project is using the JAMstack, this 404-links will become super helpful for website that relies on framework like:

Docusaurus
Hugo
Gatsby
etc…

What could be improved? How can you contribute?

So far the 404-links Github action is focused on remote links (http and https), that would be great if the Action could also check links to local files.

Don’t forget to support the 404-link Github action by giving them a star ⭐️ on github

If you want to get more update about the best way to improve your project through Continuous Integration. Follow me 😁.

Packageless - It's time to reduce your dependencies: The Supertest case.

OliverOdo — Fri, 01 Oct 2021 01:37:35 +0000

Hey 👋,
Let me share this small snippet that I hope will make you think differently.

Are you not tired of Github security bot that yelling at you about potential security issue within your package-lock.json?

YES, YES, YES!
This is why I want to share my small snippets. It's time to reduce the amount of dependencies in your project.

The Supertest use case.

Supertest is a Popular library that is used to Unit Test HTTP Server.
However Supertest depends on other libraries:

superagent (11 dependencies)
methods (0 dependencies)

Do we really need it?

Let me share the small express app that we will use for our example:

const app = express()
  .use(express.json())
  .post('/users', (req, res) => {
    res.status(201).json({ id: 1, name: 'Joe' })
  })

Supertest

Here an example on how we use super test to test a simple POST endpoint.

describe('[SUPERTEST] Http server Testing', () => {
  test('POST /users (201)', async () => {
    const response = await supertest(app)
      .post('/users')
      .send({name: 'Joe'})
    expect(response.status).toBe(201)
    const expectedBody = {
      id: 1,
      name: 'Joe'
    }
    expect(response.body).toEqual(expectedBody)
  })
})

Alternatives

I'm assuming that your project is already importing a library to perform HTTP request. And this is exactly what we will try to reuse.

1. Axios

If your project is already using axios this snippet is for you:

describe('[AXIOS] Http server Testing', () => {
  test('POST /users (201)', async () => {
    const server = app.listen(0)
    const { port } = server.address()
    const instance = axios.create({
      baseURL: `http://127.0.0.1:${port}`,
      responseType: 'json'
    })
    const response = await instance.post('users', {  name: 'Joe' })
    server.close()
    expect(response.status).toBe(201)
    const expectedBody = {
      id: 1,
      name: 'Joe'
    }
    expect(response.data).toEqual(expectedBody)
  })
})

2. GOT

If your project is already using GOT this snippet is for you:

describe('[GOT] Http server Testing', () => {
  test('POST /users (201)', async () => {
    const server = app.listen(0)
    const { port } = server.address()
    const instance = got.extend({
      prefixUrl: `http://127.0.0.1:${port}`,
      responseType: 'json'
    })
    const response = await instance.post('users', {
      json: { 
        name: 'Joe'
      }
    })
    server.close()
    expect(response.statusCode).toBe(201)
    const expectedBody = {
      id: 1,
      name: 'Joe'
    }
    expect(response.body).toEqual(expectedBody)
  })
})

3. Node Fetch

If your project is already using node fetch this snippet is for you:

describe('[FETCH] Http server Testing', () => {
  test('POST /users (201)', async () => {
    const server = app.listen(0)
    const { port } = server.address()
    const response = await fetch(`http://127.0.0.1:${port}/users`, {
      method: 'post',
      body: JSON.stringify({ name: 'Joe' }),
      headers: {'Content-Type': 'application/json'}
    });
    server.close()
    expect(response.status).toBe(201)
    const expectedBody = {
      id: 1,
      name: 'Joe'
    }
    expect(response.json()).resolves.toEqual(expectedBody)
  })
})

I hope you like it and understand how you can easily improve the long term maintenance of your project.
Let me know which flavor you like, I will share a more snippet soon.

You can find the full detail of the implementation here: https://github.com/olivierodo/nodejs-packageless/tree/main/supertest

Feel free to contribute if you know another way to reduce the dependency with supertest 😇.

Stop fighting with npm by isolating it into a container

OliverOdo — Wed, 19 May 2021 02:13:24 +0000

Hello,

Let me share a small script that i'm using on my local machine to develop.

Before we start, let me share a bit more my profile: I wrote my first line of code 15 years ago and I'm not so much into following trends... Then I develop using vim, tmux and ... bash (yes still 🤪)

As you know nowadays there is new tools, new version, new framework, new system... Installing all of this into your machine has a cost.

A new way of working by isolating projects

This is why a few years ago, I made a shift to work only within Docker container... And I LOVE IT! 🚀

I made a small script to automate the flow...

As a NodeJs developer i was tired of:

Installing global module into my computer.
Using nvm to change node version.
Having conflict between projects.
Tracking all the weird files that are installed in my HOME folder
keep trying to save space...

Now all of those problems are gone since I don't have node installed on my computer anymore, the only way I use node is through an isolated container by using this script:


#!/bin/bash

# File located in: ~/.dotfile/scripts/docker-run.sh

port=""
while getopts "p:" arg; do
  case $arg in
    p)
      for I  in "$OPTARG"
      do
        port="-p $I $port"
      done
      ;;
  esac
done

name=${PWD##*/}

docker run --name ${name} -v $(pwd):$(pwd) --workdir $(pwd) ${port} -it node:14 bash

and adding this into my ~/.bash_alias:

drun="sh ~/.dotfile/scripts/docker-run.sh"

Then when i run the alias command in a project folder:

drun -p 8080:8080

It will:

Create a fresh container with the name of the current folder
Map the 8080 port of my local machine into the 8080 port of the container.
Mount the current folder into the container.
Enter in the container.

From there, I can still edit the file from my local machine, but run any node command from the container

Example:

Conclusion

If you are still reading until here, I think you understand the potential of this. It can be use for any use case.
I also use this tips a lot, to try different programing language without installing them.

Let's break the dependency with our machine as much as possible 😇.

I forgot: Take a look at RestQA

See Ya!

More about Me:

🤓 : Blogging and Coding in English 🇬🇧 with a French accent 🇫🇷 while sitting in Thailand 🇹🇭.
🚀: API Dealer and Test automation Addict.
⭐️: Give a star to the next Open source API test automation platform
💼 : Head Of API Governance @ FWD Insurance
🐥: https://twitter.com/olivierodo