DEV Community: Sam Jones

Run a TypeScript type check in your pre-commit hook using lint-staged + husky

Sam Jones — Fri, 30 Jul 2021 15:34:51 +0000

A great way to prevent TypeScript compilation errors from bringing down your CI pipelines is to introduce a type check before you commit your .ts file changes.

If you've worked with Git Hooks before, you'll probably know that one of the best combinations for running pre-commit checks is husky and lint-staged.

Together, these two packages allow you to tap into the relevant Git hook and run commands such as linting on staged files only. It saves a bunch of debugging time by fixing preventable errors sooner in the development process.

As a separate step, if you want to check for TypeScript type errors (note: this is different to syntax errors which ESLint picks up and fixes for you), you would typically run a command in the CLI such as npx tsc --noEmit to compile the TypeScript and highlight any type errors to address.

Now, the best case scenario here is that you simply pop the above TypeScript command into your lint-staged config along with anything else e.g. ESLint, and you're good to go!

Oh no, it doesn't quite work as expected. The error message that you may come across looks something like this:

Option 'project' cannot be mixed with source files on a command line.

The issue I found - and at the time of writing, it is still being discussed - is that lint-staged would pass each staged file to the npx tsc command like npx tsc --noEmit file1.ts file2.ts and that causes TypeScript to simply ignore your tsconfig.json.

Super frustrating!

Fear not however, as there is an extremely helpful tool that runs tsc on specific files without ignoring tsconfig.json and it's called tsc-files. As the tool's author points out:

I wanted to type-check only the staged files with lint-staged.

Perfect for my use case. So, after a quick look at the docs, it was as simple as updating the lint-staged config in my package.json file to use the tsc-files package:

{
  "husky": {
    "pre-commit": "lint-staged"
  },
  "lint-staged": {
    "**/*.ts": "tsc-files --noEmit"
  }
}

Conclusion

Now I am able to run a TypeScript type check on all my staged files using a pre-commit hook.

Tip: use the --pretty flag in the tsc command to add some formatting and colour to your type errors.

If you have any questions on this setup or have tried different approaches, feel free to comment below or start up a convo over on Twitter.

Thanks for reading 👋

Create simple and stylish notifications in React using react-toastify

Sam Jones — Mon, 29 Mar 2021 15:52:26 +0000

Intro

While working on my latest side project, Code Anagrams, I wanted to display a notification whenever a user correctly answered an anagram as well as to display error messages a little more elegantly. At my current job, we use react-toastify for notifications and alerts, so I decided to reach for this package again and document my journey of configuring and implementing this particular solution.

Tutorial

Let's get started then.

More often than not, we need to implement notifications/alerts in multiple places within our codebase, so this is a perfect use case to create a util - let's call it "toast" - that we can simply import and use in various components.

In a utils folder, create a folder called toast and add an index.js file. For our first step, we will need to install our npm package:

npm i react-toastify --save

and import it (along with associated CSS) to our index.js file:

import { toast } from "react-toastify";
import "react-toastify/dist/ReactToastify.css";

Fortunately, react-toastify provides you with a ton of versatility and you can configure your notifications in various ways, which is great. But for the purposes of this tutorial, I'll just set a couple of defaults for autoClose and position:

import { toast } from "react-toastify";
import "react-toastify/dist/ReactToastify.css";

toast.configure({ autoClose: 2000, position: toast.POSITION.BOTTOM_CENTER });

Next, let's create our functions that render a successful notification (green) and an error alert (red):

import { toast } from "react-toastify";
import "react-toastify/dist/ReactToastify.css";

toast.configure({ autoClose: 2000, position: toast.POSITION.BOTTOM_CENTER });

// add more config via the options object
const successToast = (message, options = {}) =>
  toast.success(message, {
    ...options,
  });

const errorToast = (message, options = {}) =>
  toast.error(message, {
    ...options,
  });

export { successToast, errorToast };

And there we have it! You can now import this util into your component like this:

import { successAlert, errorAlert } from "./utils/toast";

successAlert("Hey there!");
errorAlert("Oops, something went wrong!");

Conclusion

In this post, we created a simple, stylish and shareable toast util that should help with implementing notifications and alerts in our web applications.

If you feel like using react-toastify in your app after reading this post, I strongly recommend heading over to the demo page and playing around with the different configurations.

Thanks for reading! 👋

5 ways to help the environment as a software developer

Sam Jones — Thu, 28 Jan 2021 13:40:56 +0000

During these strange and self-isolating times, as a software developer, it is hard to think of ways to help the environment while programming away at our laptops in the home office or, in my case, at the dining room table. In the pre-Covid days, there were significant decisions to make such as cycling to work or taking public transport instead of driving; only choosing vegetarian/vegan options when eating out; or deciding to go flight-free.

In a global pandemic, these choices have now been taken out of our hands. However, as people who spend the majority of our working day (and possibly free time) in front of the computer, I still think that there are certain habits that we could change in order to make a little impact on the environment from our terminals.

Here are my 5 ways to make that small impact:

1. Ecosia

An alternative search engine that plants a tree for every 45 searches (on average) that you make.

Their servers run on 100% renewable energy and they recently passed 100 million trees planted!

Personally, I tend to use Google when searching for specific coding-related issues and Ecosia for pretty much everything else (via their Chrome extension).

Find out more here 👉 https://info.ecosia.org/about

2. Kualo

Web-hosting company whose entire global operations are powered by renewable energy. In 2020, they also committed to becoming a climate positive business.

I've not had the chance to use Kualo yet, but will definitely be buying a domain/hosting my next website with them.

Find out more 👉 https://www.kualo.co.uk/webhosting/green-web-hosting

3. Buy refurbished

Did you know that you can help the environment by buying refurbished computers?

The world's e-waste is a huge problem. Buying your next laptop, server, monitor or even headphones refurbished will massively reduce your impact on the environment.

I bought my MacBook Pro 13" refurbished around 4 years and it still runs amazingly well. Although I could still do better with buying refurbished computer accessories.

Find out more 👉 https://www.recompute.com.au/blog/top-5-environmental-benefits-of-buying-refurbished-computers/

4. Sustainability apps

There are so many great sustainability apps out there developed by talented engineering teams who share the same environmentally-conscious determination to change.

Here are a few that I've used before or currently use:

TooGoodToGo - connects people to leftover food from supermarkets, restaurants and cafes

HappyCow - find local vegan/vegetarian restaurants and health food shops

Refill - top up your re-usable water bottle at the nearest Refill water station

5. Contribute to OSS

Away from work, another option could be to research and contribute to projects dedicated to improving our environment.

This is on my todo list for 2021 and would love to get involved in a software project that increases general engagement with our environmental challenges.

Check out these 8 projects for some inspiration.

While I understand that everyone's circumstances are different in terms of technologies that can be used at work (e.g. browser extensions) or amount of spare time to contribute to open source, I have tried to offer some starting points in this post to encourage people working in the software development industry to help support the environment during these unprecedented times.

If you have any other tips or habits that you practice to help the planet from a tech perspective, please let me know in the comments below or over on Twitter.

Thanks for reading 👋

10 Git aliases that will save time and boost productivity

Sam Jones — Mon, 11 Jan 2021 11:06:03 +0000

Like most software developers, I spend a lot of my time in the terminal writing Git commands such as status, commit and push (you know the drill), but when you actually add up all those keystrokes and realise how many seconds/minutes/hours you spend on writing them, that is exactly what it becomes - a lot of time.

It was pretty early on in my career that I started looking for ways to reduce the time I spent writing Git commands as it was a simple, repetitive task that was ripe for automation. I was then told about aliases and set about creating my own.

Note: My terminal setup is currently iTerm2 + zsh + Oh My Zsh. Here's a helpful guide to install this setup on your machine.

All of my aliases live in the ./zshrc file at root and they follow this syntax:

alias myalias='echo hello new alias'

Here is the complete list of all 10 Git aliases that I use on a daily basis:

alias gs='git status'
alias gc='git commit -m'
alias ga='git add'
alias gr='git reset HEAD'
alias m='git checkout master'
alias gd='git diff'
alias greb='git pull --rebase'
alias gp='git push'
alias gch='git checkout'
alias gm='git merge'

These aliases save me a ton of time and allow me to focus more on ~~copying/pasting~~ writing code. Shaving off a few seconds from every command really adds up and has definitely boosted my productivity as a whole.

PS. you can use aliases for any commands in the terminal. For example, another one of my favourites is alias cl='clear'.

Aliases are super useful and if you can get into the habit of using them, you will soon feel the benefits!

5 things I've learnt as the first tech hire at a startup

Sam Jones — Fri, 08 Jan 2021 11:31:57 +0000

Intro

Before we get into the nitty gritty, I'd like to share a little about my professional background before getting into software development. I studied French and Spanish at university, taught English abroad for a few years and then used these language skills to work in industries such as customer service and translation back in the UK. However, during my late twenties, I started feeling slightly disillusioned and uninspired with my career choices and had pretty much hit a ceiling at my previous company. With the birth of my amazing daughter and the inherent drive to make her proud, I decided to put myself through a part-time coding bootcamp and change career to software development. Time for a new challenge.

Fast forward 6 months and I graduated from Manchester Codes with some exciting skills and a deep sense of achievement. Towards the end of the bootcamp, after putting in countless hours of theory and practice while always trying to lend a helping hand in class, one of the bootcamp tutors kindly offered me a software developer role at his eCommerce fulfilment startup, JustFulfil. I accepted without hesitation and took my first step on the tech career ladder!

What I've learnt

That was 14 months ago. I've learnt so much in that time from working on small UX tickets to building full stack features that I thought I'd share some key thoughts on starting a career as a software developer at a startup.

Just a quick note to say there are many different startups out there employing different developers working on different tech stacks, so please bear in mind that this is my personal and unique experience. I am not saying that working at a startup is a breeze - there are certainly some downsides too - but I hope that this post provides you with an insight into how my development is progressing from beginner to mid-level engineer and the benefits that I've seen along the way due to working in this type of environment.

So, with that in mind, let's get started!

1. Pairing with the CTO

This was something I appreciated right from the start. Before the pandemic hit, and with a small team of 3, I would usually meet up with the CTO and we would work on tickets side-by-side. He would (and still does) encourage, advise, question and provide great mentorship. This initial experience was invaluable as I was able to work closely with such a senior developer at an early stage of my development. Plus, I started to get a clearer idea of the skills and knowledge required to reach a higher level within the tech industry.

Another side effect of this close contact was that I gained a better understanding of the company as a whole, which greatly helped my ability to implement business logic as well as my confidence to become more involved with discussions regarding the tech roadmap. In addition, I was able to shadow him as he planned and implemented certain infrastructure solutions such as using Docker containers for our local MySQL instances. It's always great to watch an expert at work!

2. Working full stack

At a startup, you don't have the luxury of cherry picking a nice UI ticket or playing around with a low priority bug. There are too many new features and critical issues to address that there is simply no time to figure out your "area of expertise". Whether it's UX/UI fixes, database migrations or authentication, you will inevitably need to help out in all areas.

I started my role in the September and spent the first month or so tackling front-end issues and contributing to new features. The following month, I moved on to back-end tickets where I became more familiar with the API and database structure. By Christmas that year, I was in a position to pick up whatever ticket was the highest priority across the whole stack and plan my workload appropriately.

While coding relentlessly on a daily basis helps with your progress, doing it efficiently is not possible without excellent mentoring, support and patience from senior developers. It is tough getting told halfway through a ticket where you've spent hours working on that it may be better to go in a different direction - what makes the difficult next step easier is constructive feedback and proactive encouragement from above.

3. Growing with the codebase

Like watching a young plant grow, seeing a codebase grow with you is just as satisfying. In the space of a year, our codebase has grown so much that it's easy to forget how many lines of code have been written in that time. One of my favourite things is coming across a snippet of my old (and not so well-written) code, taking some time out to refactor it and reflecting on my progress as a developer.

Getting to a stage where you are familiar with all (or most) areas of the codebase is very pleasing and can give you a huge confidence boost, especially when it comes to debugging. Plus, my productivity has significantly increased as I no longer need to build components or integrations from scratch, the essential pieces are already in place and I simply need to borrow and adjust the relevant lines according to the latest use case.

4. Independent developer

When starting a new role, a senior developer will generally talk you through or pair with you on your first tickets in order to provide support and general guidance while you learn the ropes. Naturally, the more experience you gain, the less guidance you will need. At a startup, I feel that this process is accelerated.

While I would make mistakes and ask questions like all developers, the sheer volume of tickets meant that I would make a lot of mistakes and ask a lot of questions at the beginning - but I would learn fast. Having spent the past year learning this way, I am now confident enough to be given a brief description of a feature and I will be able to plan, design and build it myself. Inevitably, there will still be questions and discussions, but there won't be as many blockers and as a result I feel more independent and more trusted by the team.

5. Extra curricular

One of the pleasant surprises of joining a startup in the early stages is that you can pitch an idea to the team and then run with it yourself (if you can fit it into your schedule!). It's useful to change focus sometimes and leave the code to one side while you contribute in a different way. For example, right now I manage the company Twitter account and send out a weekly email to our clients with the latest tech updates. These latest tasks have definitely helped me to improve my content writing skills. My aim for 2021 is to focus a little more on our documentation in order to facilitate the onboarding of new developers and give talks at meet-ups/events regarding a particularly fun subject that I've worked on.

Conclusion

Working at a startup is as hard as the next job, however I have seen some benefits in the past year that have helped me to become a more capable and well-rounded developer in a relatively short period of time. Perhaps these experiences would not be possible at a larger, more established company with rigid processes and several dev teams?

As I've said before, I won't say that working at a startup is better than working at a digital agency filled with PMs, engineers, designers and testers. There will be advantages to working in both environments. I was lucky enough to have that decision taken out of my hands and I'm very grateful for the amazing opportunity at the start of my career.

If you've worked or are working at a startup as a software developer, let me know what benefits (if any!) you've experienced while working at the company or ask me anything over on Twitter.

Thanks for reading! 👋

Using console.dir() to print JavaScript objects in the console

Sam Jones — Wed, 11 Nov 2020 11:05:40 +0000

It usually happens when you need to quickly debug something. You want to check what an object looks like at a certain point in your code, so you print it out to the console. Naturally, you wrap the object in a console.log() statement, run the logic and wait for the printed output. But no. Instead of the expected object with all of its properties showing up in the console, you are given the ever unhelpful [Object] or [Array] elements.

This has happened to me so many times that I just wish there was an in-built console method which would JSON stringify an object by default and print to the console, something like console.stringify(obj). Alas, we are stuck with wrapping our object in a JSON.stringify() and then wrapping it again in our console.log() statement.

A quick note that the current approach of using JSON.stringify() - along with the replacer and space parameters - is perfectly valid and looks a little like this:


console.log(JSON.stringify(obj, null, 2));

There is nothing wrong with this solution and it works fine if you want to see everything in JSON format. But what if you want to see the object for what it is - a JavaScript object?

Let's look at an example :


const nestedObject = {
  consignments: [
    {
      consignmentId: 1,
      orders: [
        {
          orderId: 1,
          orderLines: [
            {
              productId: 123,
              productRef: "Red Jumper",
              orderComponents: [
                {
                  componentRef: "COMP-001",
                  price: null,
                  qty: 3
                }
              ]
            }
          ]
        }
      ]
    }
  ]
};

Here, we have a very nested object where we are trying to debug an issue with the price field in the orderComponents array. If we simply use console.log() to print out the object, we will get the following (not very helpful) output in our console:

console.log(nestedObject);

// Output
{ consignments: [ { consignmentId: 1, orders: [Array] } ] }

If we used our old friend JSON.stringify() to print out the entire object, we would get the following:

console.log(JSON.stringify(nestedObject, null, 2));

// Output
{
  "consignments": [
    {
      "consignmentId": 1,
      "orders": [
        {
          "orderId": 1,
          "orderLines": [
            {
              "productId": 123,
              "productRef": "Red Jumper",
              "orderComponents": [
                {
                  "componentRef": "COMP-001",
                  "price": null,
                  "qty": 3
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

That works! We can see that the price field is suspiciously set to null, so we can carry on with our debugging. Again, there is nothing wrong with this method. In this post, I'm simply providing an alternative way.

For the same result, but displaying the output in a simple JavaScript object showing all its properties, we can take advantage of console.dir() along with one key parameter called depth. Let's take a look:

console.dir(nestedObject, { depth: null });

// Output
{ consignments:
   [ { consignmentId: 1,
       orders:
        [ { orderId: 1,
            orderLines:
             [ { productId: 123,
                 productRef: 'Red Jumper',
                 orderComponents: [ { componentRef: 'COMP-001', price: null, qty: 3 } ] } ] } ] } ] }

Setting the depth parameter to null is essential for this trick to work as it removes the limit of the object's depth, so we can view all levels of the nested object.

Note: Remember that the object depth is unlimited. For example, when using the Moment.js library, this method will print out the entire Moment date object if you have moment.utc() as one of the object values. In which case, JSON.stringify() is probably the cleaner option.

In this post, we learnt a different way of printing JavaScript objects to the console using the console.dir() method. It helps us to see all the properties of a specified JavaScript object in the console without converting to JSON format.

You may continue to use JSON.stringify() after reading this post (I probably will too!), but having seen the advantages of using console.dir(), at least we have another option now!

If you have any questions or feedback on this post, feel free to comment below or start a conversation over on Twitter.

Thanks for reading!

Convert an array of objects to CSV string in JavaScript

Sam Jones — Thu, 29 Oct 2020 19:27:29 +0000

On some occasions at work, we've needed to generate a CSV string on the server-side to send to our front-end app where the user can download a spreadsheet file e.g. report.

Naturally, there are already packages out there that can handle a variety of CSV use cases, but we just wanted a simple solution in JavaScript as we knew that the data structure coming from our database was always going to be an array of objects.

Before we continue though, it's worth pointing out that we'll be using a few JavaScript methods and techniques in the solution that you may or may not already be familiar with:

If any of the above seem a little alien to you right now, then feel free to take a quick pause here to check them out and come back when you're feeling more comfortable with them.

Welcome back if you took that break 👋

So, how do we get from an array of objects to a CSV string while ensuring that the correct data will be displayed in the column headers and rows?

Let's start by creating our array of objects:

const itemsArray = [
      { itemId: 1, itemRef: "Item 001" },
      { itemId: 2, itemRef: "Item 002" },
      { itemId: 3, itemRef: "Item 003" }
    ];

The first step towards creating the CSV string is to define our column headers and extract the key-value pairs into their own arrays:

const csvString = [
    [
      "Item ID",
      "Item Reference"
    ],
    ...itemsArray.map(item => [
      item.itemId,
      item.itemRef
    ])
  ];

console.log(csvString);
/*
   [
    ["Item ID", "Item Reference"],
    [1, "Item 001"],
    [2, "Item 002"],
    [3, "Item 003"]
   ]
*/

Now that we have all our data in arrays, we can use our .map() and .join() methods to bring everything together:

const csvString = [
    [
      "Item ID",
      "Item Reference"
    ],
    ...itemsArray.map(item => [
      item.itemId,
      item.itemRef
    ])
  ]
   .map(e => e.join(",")) 
   .join("\n");

console.log(csvString);
/*
  "Item ID,Item Reference
  1,Item 001
  2,Item 002
  3,Item 003"
*/

What happens here then? Well, the first map/join combo combines the array of 4 arrays into a single array containing the headers and key-value pairs as string types e.g. "1,Item 001". Then, the final join is needed to convert the single array into a string.

In this post, we managed to convert an array of objects into a CSV string using some helpful array methods and the spread syntax in JavaScript.

Please copy and experiment with the above code and feel free to ask me any questions on here or over on Twitter.

Thanks for reading!

Using proxyquire and sinon for unit testing in Node.js

Sam Jones — Mon, 10 Aug 2020 11:13:34 +0000

Intro

Let me start by saying that, as a beginner, I found testing to be pretty tedious and complicated. I just wanted to create an app that was going to make millions and to hell with the test coverage! However, having spent the last year working across the full stack and writing a lot of unit and integration tests in the process, I am now more at peace with the testing gurus and appreciate the genuine value that tests can bring to your codebase. While it does require a slight change of perspective, testing should feel like taking a gentle stroll through the countryside away from the hustle and bustle of business logic.

Practical

Diving straight into our scenario then. We simply want to test our function that fetches UK bank holiday dates from this URL - https://www.gov.uk/bank-holidays.json. A use case for this API could potentially be a serverless function that runs annually to fetch all bank holiday dates for that year in order to better manage dispatch/delivery times for a logistics company.

Let's pause here to review the packages that we will be using:

proxyquire: overrides dependencies
sinon: provides us with mocks (or stubs, in this case)
node-fetch: fetches our data

Note: The above packages work with any testing framework, but I'll be using Mocha and Chai in this particular example.

Create files

Let's start by creating our getBankHolidays function:

// index.js

const fetch = require("node-fetch");

const BANK_HOLIDAY_URL = "https://www.gov.uk/bank-holidays.json";

const getBankHolidays = async () => {
  try {
    const bankHolidaysResponse = await fetch(BANK_HOLIDAY_URL);

    return bankHolidaysResponse;
  } catch (err) {
    throw err;
  }
};

module.exports = getBankHolidays;

And then the test file:

// test.js

const mocha = require("mocha");
const { expect } = require("chai");
const getBankHolidays = require("./index.js");

mocha.describe("getBankHolidays", () => {

  it("should get UK Bank Holidays", async () => {
    const bankHolidays = await getBankHolidays();

    expect(bankHolidays).to.contain.keys([
      "england-and-wales",
      "northern-ireland",
      "scotland"
    ]);
  });
});

Start testing

If we run the test suite, it should pass. The call to the URL will have succeeded and the response returned will contain the expected keys.

But what if, for example, our app also relies on data from a Weather API?

We would also need to write a test for this new logic and make yet another call to a 3rd party service. Many integrations and API calls later, your testing suite could include several unit tests making various calls to live APIs. You may start to notice your CI/CD pipelines taking longer to complete or a few bugs may creep into your tests if, for example, a particular endpoint starts returning a 500 status. Or maybe the external API does not even offer a test/sandbox environment for you to use.

Clearly, there are many reasons why you shouldn't make API calls in your tests, so a great way to avoid making them in the first place is to mock the calls themselves and, if necessary, mock the response payload. Having control over both the call and response provides you with some key benefits:

Speeds up testing
Easier to identify problems
More secure (due to not sharing production API credentials with CI environment)

Let me show you what I mean by coming back to our example (now with our mock request and response defined):

// mock.json

{
  "england-and-wales": {
    "division": "england-and-wales",
    "events": [
      {
        "title": "New Year’s Day",
        "date": "2021-01-01",
        "notes": "",
        "bunting": true
      }
    ]
   },
 "northern-ireland": {
    "division": "northern-ireland",
    "events": [
      {
        "title": "New Year’s Day",
        "date": "2021-01-01",
        "notes": "",
        "bunting": true
      }
    ]
   },
 "scotland": {
    "division": "scotland",
    "events": [
      {
        "title": "New Year’s Day",
        "date": "2021-01-01",
        "notes": "",
        "bunting": true
      }
    ]
   }
}

// test.js

const mocha = require("mocha");
const { expect } = require("chai");
const proxyquire = require("proxyquire");
const sinon = require("sinon");
const MOCK_BANK_HOLIDAYS = require("./mock.json");

mocha.describe("getBankHolidays", () => {

  const fetchStub = sinon.stub();
  fetchStub.resolves(MOCK_BANK_HOLIDAYS);

  const getBankHolidays = proxyquire(
     "~/Projects/exampleTest/index.js",
     {
      "node-fetch": fetchStub
     }
    );

  it("should get UK Bank Holidays", async () => {
    await getBankHolidays();

    expect(fetchStub).to.have.been.calledOnceWithExactly(
       "https://www.gov.uk/bank-holidays.json"
      );
  });
});

So, what exactly is happening here? Basically, proxyquire is now intercepting that API call and returning the mock data as specified in our sinon stub. In other words, from proxyquire's perspective: "If I see the getBankHolidays module, I will replace the node-fetch dependency with the provided stub". This means that we avoid making the external API call and can slightly change our expectations too. Instead of testing the response (which is now mocked), we can put an expectation against the request payload being sent. If this is valid, then we can safely assume that the API is correctly set up and will return the correct response.

Note: make sure your mock data replicates that which is returned by the external API in order to correctly test the outcomes and provide a valid comparison.

Conclusion

That was pretty fun, right? Nothing too tedious or complicated, I hope!

So, when testing logic that involves communicating with an external API, try using these packages to mock your calls. Having more control over this area will speed up your tests and allow you to quickly identify and resolve any issues.

For more examples, head over to proxyquire and sinon and check out their excellent docs. And for a different solution, you can also look into nock which simplifies further what we've talked about today and provides some additional capabilities.

Thanks for reading!