DEV Community: w

Javascript Dates are Still Confusing in 2022 📅

Mon, 01 Aug 2022 12:08:40 +0000

Javascript can be a humbling language at times (or even downright frustrating 😡!), especially when working with dates. I recently had an odd experience where I had written unit tests for a new feature I was finishing at work. When I ran the tests on my machine, they all passed ✅. However, much to my dismay at 4:30pm on a Thursday, when the tests ran in our continuous integration environment, the dates were coming out one day off! Here you can see exhibit A, the seemingly innocuous line of code responsible for generating my "mock date" in my test.

(Disclaimer: The input date format was not decided by me, but is how a date representation comes back from an API that my app is dependent on.)

const date = new Date('2022-07-01');

console.log(new Date(date).toLocaleDateString()); // 6/30/2022

Where I Went Wrong

First off, I should have recognized that it wasn't giving me the date I put into it, but instead 1 day prior. However, since date formatting wasn't the most important piece of what I was working on at the time, and given it was the end of the day and I was tired, I didn't notice that the date saved in my snapshot was 1 day behind what I was putting in.

Fast forward to the test code running in our CI environment - and 💣 - it failed! I thought to myself, how could this be? I'm a professional Typescript / Javascript developer - surely I knew all the quirks of this language by now right!!??

This caused me to do some testing, thinking, and finally (what I should have done from the beginning) some googling - which landed me here:

https://stackoverflow.com/questions/7556591/is-the-javascript-date-object-always-one-day-off#:~:text=Javascript's Date class doesn't,%3A00 GMT-0400

The Culprit

As it turns out, when constructing a Date using a string formatted like such YYYY-MM-DD, the Date.parse method uses a more strict form of the date input string specification - ISO-8601. This causes it to be parsed from the UTC frame of reference, at midnight no less. Since I am in an America/New_York timezone (-4:00 EST or -5:00 EDT depending on the time of year) - midnight on any given day in UTC time is always "one day prior" in EST or EDT time - 🤯.

There are two strategies you can employ when dealing with this slightly wonky behavior.

How I Dealt With It

So in my case, I needed to change the formatting of the timestamp slightly so that it fit our UI correctly. The source API gave me guaranteed dates in the EST/EDT timezone, and always in the format of YYYY-MM-DD. Knowing this, I could simply refer to my created javascript date object in UTC time, since that's how it's getting parsed. This would prevent any accidental "1 day off" transformations, allowing me to apply my formatting and ensuring I'll always keep the date the exact same as the input date (assuming the input date's timezone is what I want to "keep" - which is true in this case).

function formatDateString(dateString: string) {
  const date = new Date(dateString);

  let day: string | number = date.getUTCDate();
  day = day >= 10 ? day : "0" + day;

  let month: string | number = date.getUTCMonth() + 1; // another JS quirk - month's are zero indexed 0-11
  month = month >= 10 ? month : "0" + month;

  const year = date.getUTCFullYear();

  return `${month}/${day}/${year}`;
}

console.log(formatDateString("2022-07-01")); // 07/01/2022

Conclusion

I try not to work with dates directly too much, but rather use a library like date-fns or dayjs. In this case, I thought to myself "this is a simple date format transformation, what could go wrong?" In the end, an extra 30 minutes of my life spent getting it right, however overall I'm grateful for seeing this language quirk that I previously wasn't aware of!

The CommonJS vs ES Modules "War" is Taxing for Us Regular Folks Out Here - One Way To Interop

Tue, 29 Mar 2022 02:52:42 +0000

You can get through this article without being an expert on either, but if you want details, I recommend checking out the commonjs vs es modules here. If you already know a little, the next bit shouldn't be too much to digest!

There are a few paths forward to interoperability (in most cases I know of at least) that are relatively painless. The ecosystem hasn't landed on the right conventions to support ESM in a reasonable way, especially (unfortunately for a lot of us) when using a TypeScript project - so unfortunately we have to piece a few things together. It additionally doesn't help that some package owners out there seem to be trying to "force" people to adopt ESM by only releasing ESM versions of their packages. (Not trying to throw shade here - I get it - I just don't love it given churn it causes for lack of the node.js loader api and many modules taking different approaches to compatibility - or none at all.) In my opinion, it simply doesn't make sense for most larger codebases to mass migrate to ESM at the time of this writing due to high complexity and very low benefit, and I mean very low benefit. Instead, I recommend one of two approaches, each of which I'll describe below.

Is it "Bad" to Stay on CommonJS Since The Standard is Becoming ES Modules?

First off, you may be wondering why stay commonjs with TypeScript (for now)?

I don't want to add .js to all my local imports
I use some test runner / mocking solution that doesn't support ES Modules
I use open telemetry runtime instrumentation that needs "require"
I don't care about top level await
I don't particularly need the proposed "security" benefits of ESM
I don't care about better tree shaking (which bundlers handling CommonJS appear to do just fine anyways) because I'm on a server. (And if you're in a serverless environment - I say maybe, but I still think bundling is an anti-pattern on the server).

If you can get away with it, then I would, at least for now. However, you may have that one dependency that decided to go full ESM and no longer support CJS, and now you're wondering "how can I upgrade myself without going all in on ESM?"

Option 1 - Use A Dynamic Import Wrapper to Import the ES Module in Question Into CommonJS

Let's use a boilerplate nest.js app here as a reference that you start with right after running their code generator for scaffolding a new backend.



npm i -g @nestjs/cli
nest new es-modules-interop-test
cd es-modules-interop-test
npm run start:dev

Everything works fine right? Not for long! Let's add one of those pesky "ES Modules Only" packages and figure out a path forward. At the time of this writing, got is one of these. (Again disclaimer about throwing shade - this is not an attempt to say one person in this argument is wrong, my intention here is to demonstrate how to deal with the pain this "ecosystem split" has caused in a sane way.)



npm install got

Rewrite your boilerplate app.service.ts as:



import { Injectable } from '@nestjs/common';
import got from 'got';

@Injectable()
export class AppService {
  async getHello(): Promise<string> {
    return got
      .get<{ origin: string }>('https://httpbin.org/ip', {
        resolveBodyOnly: true,
      })
      .then((body) => body.origin);
  }
}

And you app.controller.ts as:



import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): Promise<string> {
    return this.appService.getHello();
  }
}

As soon as you save, your app will fail to restart (assuming you followed the instructions to run in "dev mode"):



Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/$USER/Desktop/es-modules-interop-test/node_modules/got/dist/source/index.js
require() of ES modules is not supported.
require() of /Users/$USER/Desktop/es-modules-interop-test/node_modules/got/dist/source/index.js from /Users/$USER/Desktop/es-modules-interop-test/dist/app.service.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/$USER/Desktop/es-modules-interop-test/node_modules/got/package.json.

    at new NodeError (internal/errors.js:322:7)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1102:13)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:101:18)
    at Object.<anonymous> (/Users/$user/Desktop/es-modules-interop-test/src/app.service.ts:2:1)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)

In the case of a more heavy handed framework like nest.js, you have the ability to leverage an async factory, which is where you can leverage your dynamic import of the got package - which in fact - is allowed in CommonJS 🎉 (which means if this is the only package you need, you can upgrade without changing the rest of your repository).

Try updating the following:



// app.module.ts
import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [
    {
      provide: AppService,
      async useFactory() {
        return new AppService((await import('got')).default);
      },
    },
  ],
})
export class AppModule {}

// app.service.ts
import { Injectable } from '@nestjs/common';
import type { Got } from 'got';

@Injectable()
export class AppService {
  constructor(private got: Got) {}

  async getHello(): Promise<string> {
    return this.got
      .get<{ origin: string }>('https://httpbin.org/ip', {
        resolveBodyOnly: true,
      })
      .then((body) => body.origin);
  }
}

I know this isn't a nest.js tutorial, but essentially what's happening in the above is:

We added got as a private constructor variable in the AppService to allow "injection" of it into the service instead of a top level import
We're adding a provider factory to allow an "async" setup to pass our dynamically imported got module into our service for use.

Based on the CJS / ESM documentation this should work right!?

Nope - you'll notice again we have the same error as above! For what it's worth, if we were in regular Javascript land this would work by itself, but wouldn't you know it, TypeScript has it's own problems with this one - it's actually rewriting that dynamic import as a require statement 😢. It's even sadder to realize that there's no way around this without hiding your dynamic import from the TypeScript compiler with a hackier method. Again, if this is the only import you need a quick fix to get your codebase moving along, update app.module.ts one more time like so:



import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

const dynamicImport = async (packageName: string) =>
  new Function(`return import('${packageName}')`)();

@Module({
  imports: [],
  controllers: [AppController],
  providers: [
    {
      provide: AppService,
      async useFactory() {
        return new AppService((await dynamicImport('got')).default);
      },
    },
  ],
})
export class AppModule {}

After that, you'll notice that everything will magically start working again. You can shake your head in dissapproval all day, but this in my opinion is the least disruptive change you can possibly make to your code base and apply support of packages that decided to go "full ESM".

In summary, while it feels like a hack to dynamic import this way, it's an easy path forward that gets you what you need without a lot of extra fluff or a new build system on top of your existing TypeScript build system. You could even go so far as to wrap all your modules that need this technique into a single function return in a separate file, allowing you to expose access to all your dynamic import packages in one place, allowing easy future cleanup when the community at large has better first class support for such things.

I Thought TypeScript Decorators Were Hard - Now I Use Them To Cache Async Data

Tue, 22 Mar 2022 00:23:00 +0000

It's 3pm in the workday, I'm a bit tired, and suddenly my co-worker submitted a PR that involved a completely custom TypeScript decorator! Oh no! Those things I've seen only in the Nest.js framework that I simply "use and they just work"! Now I have to understand what's happening here and give meaningful feedback on the PR. After checking the TypeScript docs on them and reading through the examples, I understood enough to give a "lgtm!" but overall not satisfied with how I understood them at the time (turns out thankfully they aren't as hard to understand as I originally thought, even though they often use the scary .apply and this keywords in what at first look like hard to understand ways 😅).

Now, at this point in my career I felt very comfortable with backend code in several languages, one of my favorites being TypeScript. Not too long ago I stumbled onto the Nest.js framework, upon which soon after I was introduced to the concept of decorators. They read well, but figuring out how they worked under the hood was a different ball game. As it turns out, while Nest.js decorators are nice to use because of their readability and their power, they actually somewhat steer you away from how TypeScript decorators work "under the hood". I for one, fell into this Nest.js-specific understanding of decorators, and as a result for over a year I was only really able to leverage the power of TypeScript decorators within Nest.js - which is actually pretty limiting in some ways, the PR situation I was in above notwithstanding.

In short, TypeScript decorators are a way to "hook" into methods of a class to change behavior of that method behind the scenes. They can also change the behavior of an entire class, or a parameter of a class method. They cannot be used outside of javascript classes at this time. Nest.js decorators on the other hand, rely more on reflection, nest.js custom request/response pipelines, and app interceptors to set metadata and change behavior via configuration of interceptors. In my opinion while they lean on TypeScript decorators, they are very much framework specific and in some ways actually more complicated than raw TypeScript decorators. For what it's worth you can do most of what you do in Nest.js decorators, however the patterns they open up typically also correspond with a pipeline type feature of Nest, specifically interceptors, guards, and controller methods. I wanted more, I wanted to be able to use the decorator on any method.

Starting with a small example - TypeScript decorators are actually quite simple:

function AddLogDecorator(target: any, propertyName: string, descriptor: PropertyDescriptor) {
  const decoratedMethod = descriptor.value;

  descriptor.value = function() {
    console.log('add logging');
    return decoratedMethod.apply(this, arguments);
  }
}

class TestDecorator {
  @AddLogDecorator
  runTest() {
    console.log('my decorator log should show before this message');
  }
}

const instance = new TestDecorator();
instance.runTest();

Run this example yourself here!

You need a basic function that takes three arguments:

target - the class that contains your decorator
propertyName - the method name you're decorating as a string
descriptor - the reference to the class method you're decorating - in this case the runTest method.

In this example, instance.runTest() is running my anonymous function descriptor.value = function() { that I assigned - all I did was add a console.log but even at this level you can already see the potential - you can do anything you want before or after the decorated function runs!

Fast forward a few months and I'm still working in the same codebase. It's grown quite large, and some of our repeat use cases have an amount of boilerplate associated with them that would make anyone tired! Caching is a big one. We all cache things, and when possible, it shouldn't be complicated. For us, we initially wrote our caching utility class so that it could be leveraged with dependency injection and very strong typing. Something like this:

import { MyCachingClass } from './my-caching-class';

export class ClassWithCachingUseCase {
  constructor(private caching: MyCachingClass, private networking: NetworkingLayer) {}

  public async getThingsThatMightBeCached(key: string) {
    if (caching.isCached(key)) {
      return caching.getCached(key);
    }

    const freshData = await networking.getActualData(key);
    const ONE_HOUR_IN_SECONDS = 60 * 60;
    caching.setCached(key, freshData, ONE_HOUR_IN_SECONDS);

    return freshData;
  }
}

We've all seen this kind of boilerplate. It seems innocuous at first, however over time, it grows like barnacles all over the code base. An extra unit test per class, an extra side effect to test in e2e cases, extra performance testing considerations, etc. etc.

I had a thought the other day - wouldn't it be nice if I could just write something like this instead?

import { CacheResponse } from './my-caching-class';

export class ClassWithCachingUseCase {
  private static ONE_HOUR_IN_SECONDS = 60 * 60;

  constructor(private networking: NetworkingLayer) {}

  @CacheResponse(ONE_HOUR_IN_SECONDS)
  public async getThingsThatMightBeCached(key: string) {
    return networking.getActualData(key);
  }
}

Anywhere you need it, it just works!

Sure enough, after digging through the TypeScript Docs plus some creative searching on google and stackoverflow, I found a combination of "tricks" that could get me what I needed, without being overly clever. The following is a modified example straight from the TypeScript documentation decorator examples to demonstrate the caching use case:

class ClassWithCachingExample {
  responseCount = 0;
  static CACHE_TIME_SECONDS = 60 * 60;

  @CacheResponse(ClassWithCachingExample.CACHE_TIME_SECONDS)
  async doStuff() {
    return new Promise(resolve => {
      // increment response count to show initial call is not cached
      this.responseCount += 1;
      // arbitrary 5 second delay to show that after the first call, the rest will be cached
      setTimeout(() => resolve(this.responseCount), 5000);
    });
  }
}

I find it best to dive into decorators from the use case perspective - here is our class that will leverage the power of our caching decorator!'

Simple enough right? We have a class with a method on it that takes 5 seconds to execute. We want to cache that method call for 1 hour, so we add our cache decorator. The first call to that method should still take 5 seconds, but after that, every additional call for the next hour should only take the time required to pull the cached value from our cache!

// over simplified cache for demo purposes
let cacheObject: any = null;

function CacheResponse(timeInSeconds = 100) {  
  // notice this time we return a function signature - that's because
  // we want to allow decoration with an input - ie @CacheResponse(timeInSeconds)
  return function (target: any, propertyName: string, descriptor: PropertyDescriptor) {
    const decoratedMethod = descriptor.value;
    // dynamically generate a cache key with the class name + the decorated method name - should always be unique
    const cacheKey = `${target.constructor.name}#${propertyName}`

    // this can be set as async as long as it's decorated on an async function
    descriptor.value = async function () {
      console.log('calling decorated method');

      if (cacheObject) {
        console.log('cache hit - returning cache object');
        return cacheObject;
      }

      console.log('cache miss - calling actual method and caching for next time');

      // the "this" argument is correct for current scope because this is an anonymous function keyword, _not_ an arrow function
      // arguments will be all arguments
      cacheObject = await decoratedMethod.apply(this, arguments);

      return cacheObject;
    };
  }
}

// our class from earlier
class ClassWithCachingExample {
  responseCount = 0;
  static CACHE_TIME_SECONDS = 60 * 60;

  @CacheResponse(ClassWithCachingExample.CACHE_TIME_SECONDS)
  async doStuff() {
    return new Promise(resolve => {
      // increment response count to show initial call is not cached
      this.responseCount += 1;
      // arbitrary 5 second delay to show that after the first call, the rest will be cached
      setTimeout(() => resolve(this.responseCount), 5000);
    });
  }
}

// our running code to see our class + decorator in action!
const instance = new ClassWithCachingExample();

(async () => {
  console.log('first call');
  console.log(await instance.doStuff()); // 1 after a 5 second delay
  console.log('the rest of the calls');
  console.log(await instance.doStuff()); // 1 after no delay other than "awaited promise"
  console.log(await instance.doStuff()); // 1 after no delay other than "awaited promise"
  console.log(await instance.doStuff()); // 1 after no delay other than "awaited promise"
  console.log(await instance.doStuff()); // 1 after no delay other than "awaited promise"
  console.log(await instance.doStuff()); // 1 after no delay other than "awaited promise"
})();

If you'd like to run this example in a sandbox, here is a pre-baked url for the TypeScript Playground where you can run this code in the browser.

I tried to comment the example code as best I could to make it understandable as you read through it, however if you want my "aha" moments from this use case, here they are:

The example decorators in the TypeScript docs expect you to know a lot up front - it took me a surprising amount of time to figure out that I could re-assign the decorated method with an async function and "hook" into it - in my use case - implement some basic caching logic.
I had to re-educate myself on what .apply and arguments mean in vanilla javascript. They are powerful techniques, but are arguably less popular techniques in the strongly typed world of TypeScript - use them responsibly.
I still don't know how to give my cache decorator access to my Nest.js dependency injection container in a useful way - for example - I want my custom logger class injected into my decorator so that I can log cache hits / misses - this is not feasible without a true external container like awilix or some other package.

I hoped you enjoyed reading this article and that perhaps, TypeScript decorators are a little less confusing for you now. This use case definitely helped me understand them. If you enjoyed this article, share it on your favorite social media site!

Setup A Fastify App with Jest Tests the Right Way ⚡️

Tue, 12 Oct 2021 01:47:00 +0000

Setup A Fastify App with Jest Tests the Right Way ⚡️

If you've ever used the fastify-cli to generate a new fastify app only to find out it uses a package called "tap" to write your tests, you might have been dissappoined. I also shared this dissappointment. While there are many good reasons to use tap instead of jest for your tests in your fastify app, it may be more than you're trying to "bite off" when first learning the fastify ecosystem. If this sounds similar to your experience, then look no further - I have you covered. Setup Jest tests in a brand new Fastify app the right way with this short guide.

By the way, if you prefer video tutorials or jumping straight into the code examples yourself, check them out here:

Video Tutorial of this Article

GitHub Code

Get Going With A Fastify App

A quick run of the following will get you running with a new fastify app:

npm i -g fastify-cli;
fastify generate fastify-setup-with-jest --lang=ts;
cd fastify-setup-with-jest && npm i;

That should get you a standard fastify typescript boilerplate app. We'll take on the next steps a couple at a time.

Getting Jest Dependencies

Even though right now we have a starter app with tap tests, we can pretty quickly swap tap out for jest. First lets get those jest dependencies installed:

npm i jest ts-jest @types/jest;
npx ts-jest config:init;

This should get you setup with required jest dependencies and a simple jest config file to allow running your tests with ts-jest and typescript. Now all we need to do is complete a slight refactor of our tap formatted tests and we're done!

Swapping Tap for Jest - Test Setup

You'll notice we have integration tests - tests that actually "call" our endpoints within our fastify app via fastify.inject. These can be accommodated via a simple refactor to the helper.ts file. We just need to use jest lifecycle methods instead.

// helper.ts

import Fastify from "fastify";
import fp from "fastify-plugin";
import App from "../src/app";

export function build() {
  const app = Fastify();

  beforeAll(async () => {
    void app.register(fp(App));
    await app.ready();
  });

  afterAll(() => app.close());

  return app;
}

Notice how we have a synchronous function that returns a fastify app instance while we can use jest's asynchronous lifecycle functions beforeAll and afterAll to register our app and it's plugin dependencies and wait for everything to be ready. This way we can get the fastify app instance within our test file describe blocks without having to actually do any asynchronous work, or messy let declarations with re-assignments. It's simply much cleaner this way.

We can also use the afterAll hook to correctly shutdown the fastify instance. One last point of note - we don't actually need to call .listen() on the app instance thanks to the excellent API provided by fastify's core method fastify.inject which we'll see in our test files.

Now that we have the main way to instantiate our fastify server for integration tests the "jest" way, we can refactor our actual tests!

Refactoring the Tests

When refactoring all of the existing tests, the changes we have to make fall into one of three categories.

Removing import references to `tap` like the following:

import { test } from "tap";

Removing the `t` parameter from the `test` function callbacks:

test("default root route", async (t) => {

This is actually paramount - if you don't do this then jest will think you've used the done callback style of test and your tests will timeout. If you accidentally do this without realizing it will be hard to debug. Ask me how I know 😉.

Updating the `t` based assertions to normal `jest` assertions:

From:

t.same(JSON.parse(res.payload), { root: true });

To:

expect(res.json()).toEqual({ root: true });

Lastly, since most of your test files only have one test, you'll see that the "testing" version of the fastify app (think back to our build() function from our helpers.ts file) gets instantiated within the test function blocks directly like so:

import { build } from "../helper";

test("default root route", async () => {
  const app = build();
  const res = await app.inject({
    url: "/",
  });
  expect(res.json()).toEqual({ root: true });
});

This will work fine when there's only one test, however if you have multiple tests per file, re-instantiating the "testing" version of the fastify server is an expensive operation. You can re-use the existing test app instance by doing the following:

import { build } from "../helper";

const app = build();

test("default root route", async () => {
  const res = await app.inject({
    url: "/",
  });
  expect(res.json()).toEqual({ root: true });
});

test("some other root test", async () => {
  const res = await app.inject({ url: "/root2" });

  expect(res.json()).toEqual({ root2: true });
});

Simple as that! Now you can write multiple tests per file against your "test bed" version of your fastify app with really clean and simple syntax.

Conclusion

Thanks for tuning in, I hope you found this technique as helpful as I did. If you're interested in a video tutorial version of this article, check out my video walkthrough of this technique here:

Video Tutorial of this Article

GitHub Code

How To Automate Code Cleanliness in VSCode with Typescript, ESLint, and Prettier

Wed, 09 Jun 2021 02:54:05 +0000

I'm a fan of automating this type of thing since I do it in almost every project I ever start up. I just like the autoformatting and clean look of the code too much to go without now (probably says something about my personality).

NOTE: If you want a Node.js script that you can run in your repository and automate the entire thing without worrying about the individual pieces, feel free to skip down to my GitHub Gist at the bottom of this post!

To do this quickly we're going to use some codegen to get things up and running with fastify-cli to quickly generate us a boilerplate Typescript project.

npm i -g fastify-cli
fastify generate my-repo && cd my-repo && npm i

You now have a nice boilerplate. You can read more about fastify at fastify.io as that's not the point of this writeup. Now on to the best part!

Run npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser prettier eslint-config-prettier eslint-plugin-prettier to just go ahead and install everything at once. Keep in mind no matter how you do this you'll have to restart vscode to get the settings to take effect in this repo but the short story here is that all of these packages are pieces of what you need to get this working. It feels like a lot to me too (every time), that's why I have it written down.

You need a base eslint config file to drive your rule set. The order of the extends: property matters so don't change it unless you know what you're doing.

echo """
{
    \"parser\": \"@typescript-eslint/parser\",
    \"parserOptions\": {
        \"ecmaVersion\": 2021
    },
    \"extends\": [
        \"eslint:recommended\",
        \"plugin:@typescript-eslint/recommended\",
        \"plugin:prettier/recommended\"
    ]
}
""" > .eslintrc

You also need a prettier config file (hey at least the 5 npm packages you installed above get the autoformatting correct after this).

echo """
{
  \"semi\":  true,
  \"trailingComma\":  \"all\",
  \"singleQuote\":  true
}

""" > .prettierrc

I like prettier a certain way and chances are you folks out there do too. Customize the above generated file however you want!

Install the eslint extension for vscode too.

Lastly we have to change a few settings in VSCode and then restart it. I always make sure I have these settings set in my workspace settings.json so they override anything else. If everyone on your team doesn't use vscode though you probably want to .gitignore that .vscode/settings.json.

mkdir -p .vscode && echo """
{
  \"editor.codeActionsOnSave\": {
    \"source.fixAll\": true
  }
}
""" > .vscode/settings.json

And that should do it. Go ahead and restart vscode. When it starts back up, make sure the eslint and prettier status icons in the bottom right corner don't show any errors:

If they do then re-read the above, check that you have everything, and try restarting again. If you still have no luck, then drop me a message or comment and I'll help you out!

Assuming it worked, go ahead and open any file and notice the magic! When you save it all gets formatted exactly as you specified in your eslint and prettier configurations (within reason). Certain things of course aren't capable of being auto-fixed and you'll have to fix them manually. Overall I consider this setup a huge productivity win in any Typescript codebase.

If you made it this far thanks for reading and happy coding (with wonderful auto-fixing on save) in your future projects. If you like this article or like my style then check out some of my other work on this blog and my youtube channel.

Bonus Method - Alternate Way To Script the Whole Process With Node.js

tl;dr -

wget https://gist.githubusercontent.com/wolfejw86/22a29bd6565fb679959c83c5bc40fea5/raw/b2907aac957afc96e0cb282dfe82c313684410e2/setup-typescript-eslint-prettier.js && node setup-typescript-eslint-prettier.js

Or inspect the whole gist below:

Setup Your Fastify Server With Logging The Right Way - No More Express

Fri, 04 Jun 2021 00:50:34 +0000

Learning a new Node.js framework can be daunting given the speed at which the ecosystem moves these days. Also some of the information on learning new techniques with Node.js is outdated - for example the sheer number of Express tutorials you still find out there! Express is long overdue for a replacement, and Fastify fits right in! One of the first things to consider when running a Node.js server is how to handle logging the right way. ExpressJS did not offer anything out of the box, forcing another bike shed to paint amongst your team. Fastify on the other hand recognizes that this is a critical piece of running a server and provides sensible defaults - in the case of logging - the pino logger. Join me in this article where I walk through how to setup a Fastify Node.js logger the right way, the first time.

A New Fastify Server in a Single .js File

First things first, you need a way to experiment! Learning new things can be challenging so setting yourself up for success is really important. For the duration of this article I'd recommend using the below single file fastify server:

const Fastify = require("fastify");
const server = Fastify({});

server.listen(3000, (err) => {
  server.log.info("Server listening...");
});

Setting Up The Logger Correctly

Fastify uses the pino logging package under the hood. It is leaps and bounds ahead of pretty much all other Node.js loggers out there in my opinion. It has high performance, excellent configurability, and great sensible defaults that instantly put you in the "pit of success" when using it. If you want to start off with that "sensible" configuration, all you have to do is this in your fastify server's config:

const Fastify = require("fastify");
const server = Fastify({
  logger: true, // default is false https://www.fastify.io/docs/latest/Server/#logger
});

server.listen(3000, (err) => {
  server.log.info("Server listening...");
});

I really like the idea of sensible defaults, however it can still be a bit of overhead to figure out what they are and how they work. Here's what you get by just putting logger: true:

easily accessed logger functions - ie fastify.log.info(...args) | fastify.log.error(...args) - also available as request.log.info(...args) decorated on each request
fast JSON string logging with built in request id generation and attachment to all logs "in between" requests/responses which formats great for integrations with kibana/elastic search or splunk (or name your centralize logging solution that "likes" to ingest JSON formatted strings)
automatic request id attachment to any logs that happen in between the request/response log

Example:

user A's client makes a request to the fastify backend - we get a logged incoming request with a request id
user A's request makes it through, but our db query threw an error
we logged that error using fastify.log.error - this automatically attaches that request id to this error log
Now when we get alerted that something went wrong with this user's request we see:

{ requestId: 999, url: "/my-endpoint-that-error's", sessionId: "session-123" }
{ requestId: 999, message: "my helpful database related error message", sessionId: "session-123" }
{ requestId: 999, statusCode: 500, duration: 150, sessionId: "session-123" }

You can see in a central logging system it would be easy to "correlate" the error with that user's request. Additionally you can modify the request/response logs that happen on each request to fit your use case - often times a client tracing id or a session id can add further debugging capabilities to your log stream.

### Incremental Improvements - Better Log Correlation

The first thing that catches my eye above is that the url is only logged on the first log message while the duration of the request is only logged at the end. While this makes logical sense, if you're making a dashboard from your logstream with your API endpoints and their average response times, correlating these inside of another tool can be quite frustrating. This is a great time to break out of the default mode and simply implement your own request/response logging.

The high level process to achieve this type of custom request/response logging would be to disable the default request logging and replace it with your custom implementation to get the granular data inside the logs you need on each request.

This will be a very common thing to do and should not be thought of as overly "risky" or "advanced":

  const Fastify = require("fastify");
  const server = Fastify({
    logger: true,
    disableRequestLogging: true,
  });

  const now = () => Date.now();

  server.addHook("onRequest", (req, reply, done) => {
    reply.startTime = now();
    req.log.info({ url: req.raw.url, id: req.id }, "received request");
    done();
  });

  server.addHook("onResponse", (req, reply, done) => {
    req.log.info(
      {
        url: req.raw.url, // add url to response as well for simple correlating
        statusCode: reply.raw.statusCode,
        durationMs: now() - reply.startTime, // recreate duration in ms - use process.hrtime() - https://nodejs.org/api/process.html#process_process_hrtime_bigint for most accuracy
      },
      "request completed"
    );
    done();
  });

  server.get("/hello", () => ({ ok: true }));

  server.listen(4000, (err) => {
    server.log.info("Server listening...");
  });

After the above re-implementation of request/response logging you'll be able to correlate your API urls more easily with the response times.

### Incremental Improvements - Better Request-Id Generation

The second thing I notice is that requestId's are generated based off of using autoincrementing integers. While this works great if you only have one server, in a world of containers and horizontal autoscaling this doesn't go very far as you'll get collisions which will hurt your logging accuracy and your ability to debug your log tracing. It is however really easy to override the default behavior:

  const Fastify = require("fastify");
  const uuidv4 = require("uuid").v4;
  const server = Fastify({
    logger: true,
    genReqId(req) {
      // you get access to the req here if you need it - must be a synchronous function
      return uuidv4();
    },
  });

  server.listen(3000, (err) => {
    server.log.info("Server listening...");
  });

Now with our logger and our genReqId() implementation we will have a uuid generated for each request-id - algorithmically guaranteed to be unique!

WARNING: There is a caveat for request-id generation with some additional default behavior. It is also common in distributed systems to use a client-based request-id to correlate downstream API requests. Fastify supports this out of the box, however you need to know it's there. Normally with something like OpenTelemetry you would have a request-id as well as span id's. OpenTelemetry is out of scope for this article, however just know that there is a default behavior that can allow a client sending trace ids as a header (default request-id) is supported. In this case, you would want to work out this contract with your consumers ahead of time and potentially put something in place to ensure they adhere to this practice.

Security

One excellent built in feature is the ability to redact sensitive information with pinojs. The fastify server's logger configuration is just a pass-through for pino so you can use all its features. If I know for example that I have a logger that will log sensitive information, I can easily redact it using string paths:

const Fastify = require("fastify");
const server = Fastify({
  logger: {
    redact: ["headers.authorization"],
    // an object for redact is also supported - see the docs https://getpino.io/#/docs/redaction?id=redaction
    // redact: {
    //   paths: ["headers.authorization"],
    //   remove: true,
    //   censor: "Super Secret!!",
    // },
    level: "info",
  },
});

server.get("/", async (req) => {
  req.log.info(
    { headers: req.headers },
    "Logging request headers for debugging..."
  );

  return { ok: true };
});

server.listen(3000, (err) => {
  server.log.info("Server listening...");

  // console.log used here only to log out a pre-baked curl request for you to make this example easy
  console.log(`
  # Try a curl request with sensitive info as the auth header and watch it NOT get logged:
  curl http://localhost:3000 -H "Authorization: Bearer my-secret-token-that-will-not-get-logged" -H "X-Will-Get-Logged: This header will still get logged"
  `);
});

If you run the code example above - try running the built in curl request that gets logged out. You should see that the authorization header got redacted while the other header still showed up:

{
  "level": 30,
  "time": 1622597119730,
  "pid": 98721,
  "reqId": "req-1",
  "headers": {
    "host": "localhost:3000",
    "user-agent": "curl/7.64.1",
    "accept": "*/*",
    "authorization": "[Redacted]", // notice that it got redacted - you can customize this too
    "x-will-get-logged": "This header will still get logged"
  },
  "msg": "Logging request headers for debugging..."
}

Wrap Up

This is really it - thankfully like most things with Fastify - logging is really simple to implement, even for the most complex of use cases. If you have a need for a larger abstraction to help prevent churn with log formatting, application specific static logging, and even the dreaded framework swap, it can be recommended to instantiate the logger separately rather than just passing the fastify server { logging: true }. Great news - you can easily bring your own logger. This is actually what I do for most of my larger projects at work. As long as it adheres to the logging interface (ie has a .info, .warn, .error, etc.) it will pretty much just work. For what it's worth even if you bring your own logging solution I highly recommend using pino as it's the fastest logger in town. To bring your own logger (pino) as an example, simply do this:

const logger = require("pino")({
  name: "my-application-name", // this will add `name` to every logged object
  // Check out the full list of pino options here:
  // https://getpino.io/#/docs/api?id=options
});
const Fastify = require("fastify");
const server = Fastify({ logger }); // simply pass your pino instance to the fastify config

server.listen(3000, () => {
  server.log.info("Server listening...");
});

DEV Community: w

Javascript Dates are Still Confusing in 2022 📅

Where I Went Wrong

The Culprit

How I Dealt With It

Conclusion

The CommonJS vs ES Modules "War" is Taxing for Us Regular Folks Out Here - One Way To Interop

Is it "Bad" to Stay on CommonJS Since The Standard is Becoming ES Modules?

Option 1 - Use A Dynamic Import Wrapper to Import the ES Module in Question Into CommonJS

I Thought TypeScript Decorators Were Hard - Now I Use Them To Cache Async Data

Setup A Fastify App with Jest Tests the Right Way ⚡️

Setup A Fastify App with Jest Tests the Right Way ⚡️

Get Going With A Fastify App

Getting Jest Dependencies

Swapping Tap for Jest - Test Setup

Refactoring the Tests

Removing import references to tap like the following:

Removing the t parameter from the test function callbacks:

Updating the t based assertions to normal jest assertions:

Conclusion

How To Automate Code Cleanliness in VSCode with Typescript, ESLint, and Prettier

Bonus Method - Alternate Way To Script the Whole Process With Node.js

Setup Your Fastify Server With Logging The Right Way - No More Express

A New Fastify Server in a Single .js File

Setting Up The Logger Correctly

Security

Wrap Up

References

Removing import references to `tap` like the following:

Removing the `t` parameter from the `test` function callbacks:

Updating the `t` based assertions to normal `jest` assertions: