DEV Community: Yoshihide Shiono

Upgrading to Serverless Framework v4: The Why and the How

Yoshihide Shiono — Fri, 23 Jan 2026 04:08:21 +0000

Self-Introduction

Hi there!

I'm Yoshihide Shiono, a freelance developer who absolutely loves TypeScript.

To be honest, I'm not exactly thrilled about upgrading from Serverless Framework v3 to v4. However, in this article, I'll explain why upgrading to v4 will eventually become a necessity for all of us.

What is the Serverless Framework?

The Serverless Framework is a Node.js-based tool designed to make developing and deploying serverless applications much easier.
It allows you to run code without having to worry about servers or clusters, so you can focus entirely on application development.

The Serverless Framework consists of an open-source CLI (the serverless command) and a web dashboard. By combining these, you can manage the complete lifecycle of your serverless applications.
With AWS Lambda, you can run code for virtually any type of application or backend service without needing any administration.

Differences between Serverless Framework v3 and v4

Official Blog: Serverless Framework V4 Generally Available

Licensing Changes

Up until v3, the Serverless Framework was free to use. However, starting with Serverless Framework v4, organizations with an annual revenue exceeding $2 million will need to purchase a paid subscription.
(Conversely, this means that if your annual revenue does not exceed $2 million, you can continue to use the Serverless Framework for free, just as before. It works similarly to Docker's model.)

Authentication required for every `serverless` command

Even if you don't purchase a paid subscription, authentication is required every time you run the serverless command. If you aren't authenticated, you'll be prompted to run serverless login.

This user information corresponds to an account on the web dashboard, so you'll need to register if you haven't already.
Alternatively, if an administrator already has access to the dashboard, you can use a license key issued from there to bypass the login prompt.

Focus on AWS Lambda support going forward

While previous versions supported Google Cloud, Azure, and others in addition to AWS, Serverless Framework v4 seems to be moving towards unifying development primarily around AWS.

Native TypeScript Support

serverless-esbuild, which was commonly used in v3, is no longer usable. Instead, TypeScript support is now built-in.
Currently, only esbuild is supported, but there's a possibility that other bundlers (like Webpack or Rollup) will be supported in the future.

Why we're gradually entering the era of Serverless Framework v4 (whether we like it or not)

Node.js v22 (LTS) doesn't run on Serverless Framework v3

Since Serverless Framework v4 introduces a paid model for some, there are many cases where teams would prefer to stick with v3 for as long as possible.

However, there is a shocking fact I want to shout from the rooftops:
As of March 2025, Node.js v22 does not work with Serverless Framework v3.

AWS Lambda itself announced support for Node.js v22 LTS in November 2024.

Since the EOL (End of Life) for Node.js v20 LTS is April 30, 2026, it is only a matter of time before we are forced to adopt a configuration of Serverless v4 + Node.js v22.
For this reason, at Enerbank Inc., we are also gradually proceeding with the introduction of Serverless Framework v4.

Ecosystem plugins are being absorbed into Serverless Framework v4

Not only is core development shifting to v4, but the ecosystem cultivated during the v3 era is expected to be gradually absorbed or phased out with the arrival of v4.

Let's consider the pattern of using esbuild as a TypeScript bundler.
serverless-esbuild was an external plugin in v3, but esbuild is built into the core functionality in v4. Consequently, including serverless-esbuild, serverless-webpack, or serverless-plugin-typescript will result in an error. (This is a breaking change.)

Example using esbuild in Serverless Framework v3

# serverless.yml

plugins:
  - serverless-esbuild

custom:
  esbuild:
    minify: true
    sourcemap: true

Example using esbuild in Serverless Framework v4

You can now describe esbuild settings using the build.esbuild option.

# serverless.yml

build:
  esbuild:
    bundle: true
    minify: true

You can also specify a configuration file like esbuild.config.ts.

# serverless.yml

build:
  esbuild:
    configFile: esbuild.config.ts

// esbuild.config.ts

export default () => {
  return {
    minify: true,
    sourcemap: true,
  }
}

How to run Serverless Framework v4 in GitHub Actions

Running in GitHub Actions without `serverless login`

You will need an access key named SERVERLESS_ACCESS_KEY.
Generate an access key in the Serverless Framework dashboard and use it.
Since this is sensitive information, it's best to register it in GitHub Actions secrets and reference it from there.

By passing the GitHub Actions secret to the environment variable in serverless.yml, execution will proceed normally.

# serverless.yml

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy App
        run: serverless deploy
        env:
          SERVERLESS_ACCESS_KEY: ${{ secrets.SERVERLESS_ACCESS_KEY }}

If it works locally but not in GitHub Actions

You might need NODE_OPTIONS='--openssl-legacy-provider'.

When upgrading from Node.js v16 to v18, the OpenSSL major version was upgraded from v1 to v3. Depending on the libraries you use, you may need to enable the --openssl-legacy-provider option to maintain compatibility with the older OpenSSL.

Summary

Starting with Serverless Framework v4, the licensing has changed; organizations with over $2 million in annual revenue must purchase a paid subscription.
Since Serverless Framework v3 does not support Node.js v22 (LTS), upgrading to Serverless Framework v4 is necessary.
Beyond core development, the plugin ecosystem is gradually being absorbed into Serverless Framework v4, which may force breaking changes in your project configuration.

Saying Goodbye to Husky: How Lefthook Supercharged Our TypeScript Workflow

Yoshihide Shiono — Wed, 07 Jan 2026 11:27:51 +0000

Introduction: The Unseen Impact of Git Hooks on DX

In modern Web development, maintaining code quality isn't just about "being careful" — it's about building systems that make quality inevitable. Git hooks are the unsung heroes of this mission.

For years, the gold standard for managing Git hooks in the Node.js ecosystem has been the duo of Husky and lint-staged. But as projects grow, architectures shift toward microservices, and monorepos become the norm, we’ve started to see some cracks in this "classic" setup.

We’ve all been there: you hit git commit, and then... you wait. You wait for several seconds—sometimes ten or twenty — while the checks run. We might tell ourselves it’s just a short break, but these tiny interruptions add up. They break our "flow state" and create friction in our daily rhythm.

In this post, I want to walk you through why we decided to solve this friction by migrating to Lefthook — a lightning-fast Git hook manager written in Go.

The Limits of the Past: Why Husky + lint-staged Can Feel "Heavy"

While Husky and lint-staged have served us well, they carry three specific burdens that become more apparent as a project scales:

① Node.js Runtime Overhead

Both Husky and lint-staged are built on Node.js. Every time you commit, the system has to spin up the Node runtime, load packages, and interpret scripts. For a single commit, it’s a blink of an eye. For an engineer committing dozens of times a day, it’s a cumulative tax on productivity.

② Sequential Execution Bottlenecks

By default, lint-staged usually runs commands one after another. It finishes ESLint, then starts Prettier, and so on. Even though our modern laptops have plenty of CPU cores, this sequential approach leaves that power untapped.

③ Scattered Configuration

Since Husky v8, configurations moved into shell scripts inside the .husky/ directory. Meanwhile, your file filtering logic (the lint-staged part) lives in package.json or .lintstagedrc. Having your logic split across multiple files makes it harder to see the "big picture" of what’s happening during a commit, increasing the mental load for maintenance.

Enter Lefthook: The Next-Gen Choice

Lefthook, created by the team at Evil Martians, is a Git hook manager written in Go. Its philosophy is simple: speed and simplicity.

Four Ways Lefthook Changes the Game:

Native Binary Speed: Because it’s a Go binary, there’s no waiting for Node.js to start. It’s nearly instantaneous.
Parallel Execution by Default: Just add parallel: true to your config, and your commands start running on multiple threads simultaneously.
Consolidated YAML Management: Everything — pre-commit, pre-push, commit-msg — lives in a single lefthook.yml file.
Language Agnostic: Whether you’re in a monorepo or a polyglot environment (Node, Go, Python, Rust), Lefthook handles it all with one consistent configuration.

The Migration Guide: From Husky to Lefthook

Ready to make the switch? Let's walk through the process using a modern TypeScript/Node.js project as our example.

STEP 1: The Cleanup

First, we say a respectful goodbye to our good old tools.

# Remove the old dependencies
npm uninstall husky lint-staged

# Delete the old configuration files

rm -rf .husky
rm .lintstagedrc # (if it exists)

Don’t forget to remove any prepare: "husky install" scripts from your package.json!

STEP 2: Install and Initialize Lefthook

Now, let’s bring in the new speed. For Node.js projects, installing via npm ensures everyone on your team stays in sync.

npm install lefthook --save-dev
npx lefthook install

STEP 3: Designing your `lefthook.yml`

This is where the magic happens. We’re going to build a configuration that replaces both Husky and lint-staged in one go.

# lefthook.yml

# --- pre-commit: Quality checks before the commit is finalized ---
pre-commit:
  parallel: true # Run everything at once!
  commands:
    # (1) Static analysis and auto-fixing with ESLint
    eslint:
      # {staged_files} targets only what you've added (replacing lint-staged)
      run: npx eslint {staged_files} --fix && git add {staged_files}
      glob: '*.{ts,tsx,js,jsx}'

    # (2) Code formatting with Prettier
    prettier:
      run: npx prettier --write {staged_files} && git add {staged_files}
      glob: '*.{ts,tsx,js,jsx,json,css,md,yml}'

    # (3) TypeScript Type Checking (Check the whole project)
    # Type checking is heavy, so parallel execution is a huge win here.
    type-check:
      run: npx tsc --noEmit

# --- commit-msg: Enforcing commit message standards ---
commit-msg:
  commands:
    'lint-commit-message':
      # {1} is the path to the temporary file containing your commit message
      run: npx commitlint --edit {1}

# --- pre-push: The final line of defense ---
pre-push:
  commands:
    unit-test:
      run: npm test

Why Parallel Matters

In this setup, eslint, prettier, and type-check all start at the same time. While tsc --noEmit is notoriously slow, it no longer makes you wait for the linter to finish first. Your total wait time is now just the duration of your slowest task, not the sum of all of them.

Advanced Techniques for the Real World

① Mastering Monorepos

If you have a frontend and backend in one repository, the root option is your best friend.

pre-commit:
  commands:
    frontend-lint:
      run: npm run lint {staged_files}
      root: 'packages/frontend/'
      glob: '*.{ts,tsx}'

② Emergency Skips

We’ve all had those "fix it now" moments. Lefthook makes it easy to skip hooks with environment variables.

# Skip everything
LEFTHOOK=0 git commit -m "Emergency fix"

# Skip just the linter
SKIP=eslint git commit -m "Skip lint for this one"

③ Personal Overrides with `lefthook-local.yml`

Sometimes you want a custom hook just for yourself (like a Slack notification or a specific local script). You can create a lefthook-local.yml, add it to your .gitignore, and Lefthook will merge it with the team settings. It’s the perfect way to customize your workflow without bothering your teammates.

Closing Thoughts: Better DX, One Commit at a Time

Switching from Husky to Lefthook is about more than just swapping libraries. It’s an investment in your team’s Development Experience (DX). It’s about removing those tiny "micro-frictions" that add up over a workday.

The Benefits:

Time Saved: Parallel execution can cut commit waits by 50% or more.
Clarity: One YAML file that anyone can read and understand.
Future-Proof: Built-in support for monorepos and CI/CD.

Migrating takes about 10 minutes, but the speed you gain will stay with you for every commit to come. Give it a try — your flow state will thank you!

LGTMify - An LGTM generator (Chrome Extension)

Yoshihide Shiono — Tue, 08 Mar 2022 00:50:41 +0000

Available at: Chrome Web Store

Motivation

It is already available on LGTMoon, LGTMeow and so on, but sometimes we must care about the contents of the images such as human faces.

"LGTMify" generates "Looks Good To Me" images without uploading them!

How to Use

Off　course, as explained above (GIF), there are only two features:

Select the target area (drag and resize)
"LGTMify" the target

Then it automatically opens a new tab with the base64 image!

GitHub repository

saltyshiomix/LGTMify-extension

If you like, please stargaze the repository and install LGTMify on Chrome Web Store 🙏

Thanks,

Introducing an Alternative to NEXT.js

Yoshihide Shiono — Mon, 16 Dec 2019 21:43:13 +0000

Introduction

When we develop React apps, it is one of the best choices to separate a server and a client.

But in those cases, we must implement so many APIs for the client in the server side.

On the other hand, a good old way to server render views like handlebars or ejs is not suitable for React single page apps or server side rendering apps.

Though it is not possible to use NEXT.js as a view template engine like from an Express server, but it is necessary a little tricky techniques like this:

// pages/index.tsx

const IndexPage = ({ articles }) => {
  return (
    <ul>
      {articles.map((article, index) => (
        <li key={index}>{article.title}</li>
      ))}
    </ul>
  );
};

// we must use `getInitialProps()` to enable SSR correctly
IndexPage.getInitialProps = async ({ req, query }) => {
  const isServer = !!req;

  // and we have to check a process is a server or not
  let articles;
  if (isServer) {
    // if the server side, we can receive data from the server directly
    articles = query.articles;
  } else {
    // if the client side, we must fetch data from the API server
    articles = await http.get('api/articles');
  }

  // finally, we can use data in the `IndexPage` component like above
  return {
    articles,
  };
};

Have you ever thought of the implementation like this?

// server.js

const express = require('express');

const app = express();

app.get('/', (req, res) => {
  const message = 'Hello World!';
  res.render('index', { message });
});

app.listen(3000, () => {
  console.log('> Ready on http://localhost:3000');
});

// views/index.jsx

export default function IndexPage{ message }) {
  return <p>{message}</p>;
}

And if we could see 'Hello World' by SSR?

Let's Imagine!

// server.js

const posts = [
  { id: 1, body: 'This is a first post.' },
  { id: 2, body: 'This is a second post.' },
  { id: 3, body: 'This is a last post.' },
];

app.get('/', (req, res) => {
  res.render('index', { posts });
});

app.get('/posts/:postId', (req, res) => {
  const { postId } = req.params;
  const post = findById(postId);
  res.render('post', { post });
});

// views/index.jsx

import React from 'react';

const IndexPage = ({ posts }) => {
  return (
    <React.Fragment>
      {posts.map((post, index) => {
        return (
          <p key={index}>
            <a href={'/posts/' + post.id}>{post.body}</a>
          </p>
        );
      })}
    </React.Fragment>
  );
};

export default IndexPage;

// views/post.jsx

import React from 'react';

const PostPage = ({ post }) => {
  return (
    <React.Fragment>
      <p>{post.body}</p>
    </React.Fragment>
  );
};

export default PostPage;

Is it so easy enough, right?

And we can use React as if it was a view template engine!

About `react-ssr`

saltyshiomix / react-ssr

React SSR as a view template engine

Overview

SSR (Server Side Rendering) as a view template engine
Dynamic props
- Passing the server data to the React client props
- Suitable for
  - Admin Panels
  - Blogging
Developer Experience
- Zero config of webpack and babel
- HMR (Hot Module Replacement) both scripts and even if styles when process.env.NODE_ENV !== 'production'
- Built-in Sass (SCSS) support

Pros and Cons

Pros

Because it is just a view template engine:

It doesn't need to have any APIs, all we have to do is to pass the server data to the client
It supports multiple engines like .hbs, .ejs and React .(ts|js)x
We can use passport authentication as it always is

Cons

It is not so performant, because it assembles the whole HTML on each request
It does not support client side routing

Usage

With @react-ssr/express

Install it:

$ npm install --save @react-ssr/core @react-ssr/express express react react-dom

And add a script to your package.json like this:

…

View on GitHub

Overview

Pass the server data to the React client props
- So it reacts as if it is a view template engine
- Off course, it is optimized for search engines by using server side rendering
Developer Experience
- It is so easy to use and there is almost nothing to learn the way to use
- HMR (Hot Module Replacement) when process.env !== 'production'

How to Use `react-ssr`

There are three npm packages for Express applications:

@react-ssr/core
- A core package for @react-ssr/express and @react-ssr/nestjs-express
@react-ssr/express
- A package for pure Express applications
@react-ssr/nestjs-express
- A package for NestJS Express applications

Usage of `@react-ssr/express` in JavaScript

Installation:

$ npm install --save @react-ssr/core @react-ssr/express express react react-dom

In the package.json:

{
  "scripts": {
    "start": "node server.js"
  }
}

And populate files below inside your project:

.babelrc:

{
  "presets": [
    "@react-ssr/express/babel"
  ]
}

server.js:

const express = require('express');
const register = require('@react-ssr/express/register');

const app = express();

(async () => {
  // register `.jsx` as a view template engine
  await register(app);

  app.get('/', (req, res) => {
    const message = 'Hello World!';
    res.render('index', { message });
  });

  app.listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
})();

views/index.jsx:

export default function IndexPage({ message }) {
  return <p>{message}</p>;
}

That's it!

Then just run npm start and go to http://localhost:3000, you'll see Hello World!.

Usage of `@react-ssr/express` in TypeScript

To enable TypeScript engine (.tsx), just put tsconfig.json in your project root directory.

The codes of TypeScript will be like this:

package.json:

{
  "scripts": {
    "start": "ts-node server.ts"
  }
}

server.ts:

import express, { Request, Response } from 'express';
import register from '@react-ssr/express/register';

const app = express();

(async () => {
  // register `.tsx` as a view template engine
  await register(app);

  app.get('/', (req: Request, res: Response) => {
    const message = 'Hello World!';
    res.render('index', { message });
  });

  app.listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
})();

views/index.tsx:

interface IndexPageProps {
  message: string;
}

export default function IndexPage({ message }: IndexPageProps) {
  return <p>{message}</p>;
}

Usage of `@react-ssr/nestjs-express`

Installation:

# install NestJS dependencies
$ npm install --save @nestjs/core @nestjs/common @nestjs/platform-express

# install @react-ssr/nestjs-express
$ npm install --save @react-ssr/core @react-ssr/nestjs-express react react-dom

In the package.json:

{
  "scripts": {
    "start": "ts-node --project tsconfig.server.json server/main.ts"
  }
}

And then, populate files below inside your project:

.babelrc:

{
  "presets": [
    "@react-ssr/nestjs-express/babel"
  ]
}

tsconfig.json:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "jsx": "preserve",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "strict": true,
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true
  },
  "exclude": [
    "node_modules",
    "ssr.config.js",
    ".ssr"
  ]
}

tsconfig.server.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "module": "commonjs"
  },
  "include": [
    "server"
  ]
}

server/main.ts:

import { NestFactory } from '@nestjs/core';
import { NestExpressApplication } from '@nestjs/platform-express';
import register from '@react-ssr/nestjs-express/register';
import { AppModule } from './app.module';

(async () => {
  const app = await NestFactory.create<NestExpressApplication>(AppModule);

  // register `.tsx` as a view template engine
  await register(app);

  app.listen(3000, async () => {
    console.log(`> Ready on http://localhost:3000`);
  });
})();

server/app.module.ts:

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

@Module({
  controllers: [
    AppController,
  ],
})
export class AppModule {}

server/app.controller.ts:

import {
  Controller,
  Get,
  Render,
} from '@nestjs/common';

@Controller()
export class AppController {
  @Get()
  @Render('index') // this will render `views/index.tsx`
  public showHome() {
    const user = { name: 'NestJS' };
    return { user };
  }
}

Finally, views/index.tsx:

interface IndexPageProps {
  user: any;
}

const IndexPage = ({ user }: IndexPageProps) => {
  return <p>Hello {user.name}!</p>;
};

export default IndexPage;

Then, just run npm start and go to http://localhost:3000
, you'll see Hello NestJS!.

There Are Many Examples

@react-ssr/express
@react-ssr/nestjs-express
- examples/basic-nestjs
- examples/basic-nestjs-nodemon
@react-ssr/static
- .jsx
- examples/basic-jsx-static
- examples/with-jsx-static-bulma
- .tsx
- examples/basic-tsx-static

`examples/with-jsx-antd`

`examples/with-jsx-emotion`

`examples/with-jsx-material-ui`

`examples/with-jsx-semantic-ui`

`examples/with-jsx-styled-components`

Conclusion

Please try react-ssr and send us feedbacks!

Best,

[Express] React as a View Template Engine?

Yoshihide Shiono — Mon, 14 Oct 2019 07:31:28 +0000

Updated (2019/10/29)

Thanks to kind advisors, lots of bugs are fixed and new features are added:

v0.2.6 - [fix] the cache problem
v0.3.0 - [new] support for hot reloading when process.env.NODE_ENV !== production
v0.3.1 - [fix] lots of bugs
v0.4.2 - [new] support for emotion
v0.5.5 - [new] support for material-ui
v0.5.6 - [new] support for styled-components
v0.6.1 - [new] support for NestJS
v0.7.0 - [new] ssr.config.js
v0.8.0 - [new] dynamic Head

Intro

Have you ever thought about using React as a view template engine?

If I could use React as a real view, a view template engine of Express.

But it may be difficult because React is a component oriented library, and it must be bundled by webpack or rollup and so on...

Imagine This!

package.json

{
  "scripts": {
    "start": "node server.js"
  }
}

server.js

const app = express();

app.get('/', (req, res) => {
  const message = 'Hello World!';
  res.render('index', { message });
});

app.listen(3000, () => {
  console.log('> Ready on http://localhost:3000');
});

views/index.jsx

import React from 'react';

export default function Index({ message }) {
  return <p>{message}</p>;
}

It's wonderful, isn't it?

Simple enough to learn and use it.

Please Try This! And Tell Me Your First Impression!

# installation
$ git clone https://github.com/saltyshiomix/react-ssr-starter.git
$ cd react-ssr-starter
$ yarn (or `npm install`)

# development mode
$ yarn dev (or `npm run dev`)

# production mode
$ yarn start (or `npm start`)

saltyshiomix / react-ssr-jsx-starter

An example of @react-ssr/express

This repository is the example of @react-ssr/express.

Usage

# installation
$ git clone https://github.com/saltyshiomix/react-ssr-jsx-starter.git
$ cd react-ssr-jsx-starter
$ yarn (or `npm install`)

# development mode
$ yarn dev (or `npm run dev`)

# production mode
$ yarn start (or `npm start`)

saltyshiomix/react-ssr - React SSR as a view template engine

View on GitHub

About @react-ssr/express

saltyshiomix / react-ssr

React SSR as a view template engine

Overview

SSR (Server Side Rendering) as a view template engine
Dynamic props
- Passing the server data to the React client props
- Suitable for
  - Admin Panels
  - Blogging
Developer Experience
- Zero config of webpack and babel
- HMR (Hot Module Replacement) both scripts and even if styles when process.env.NODE_ENV !== 'production'
- Built-in Sass (SCSS) support

Pros and Cons

Pros

Because it is just a view template engine:

It doesn't need to have any APIs, all we have to do is to pass the server data to the client
It supports multiple engines like .hbs, .ejs and React .(ts|js)x
We can use passport authentication as it always is

Cons

It is not so performant, because it assembles the whole HTML on each request
It does not support client side routing

Usage

With @react-ssr/express

Install it:

$ npm install --save @react-ssr/core @react-ssr/express express react react-dom

And add a script to your package.json like this:

…

View on GitHub

Conclusion

May the code be with you.

Thank you for all!!!

Dear,

Learn the Redux Architecture by Creating the Minimal TODO App on top of NEXT.js

Yoshihide Shiono — Sat, 12 Oct 2019 10:47:50 +0000

In this article, I'll explain the React Redux architecture by creating so simple TODO app which has just only two features (ADD TODO and DELETE TODO).

This is a step by step guide of the example repo here:

saltyshiomix / nextjs-redux-todo-app

A minimal todo app with NEXT.js on the redux architecture

Features

Minimal but well structured
No CSS, only TypeScript
We can learn these stacks:
- next
- react
- redux and react-redux
- redux-thunk
- reselect
- recompose

Usage

# installation
$ git clone https://github.com/saltyshiomix/nextjs-todo-app.git
$ cd nextjs-todo-app
$ yarn (or `npm install`)

# development mode
$ yarn dev (or `npm run dev`)

# production mode
$ yarn build (or `npm run build`)
$ yarn start (or `npm start`)

View on GitHub

The Point of View

Minimal features
- Add TODO
- Delete TODO
Only TypeScript
- No database
- No CSS
We can learn these stacks:
- next
- react
- redux and react-redux
- redux-thunk
- reselect
- recompose

Folder Structures

NEXT.js Structures

.
├── components
│   ├── page.tsx
│   └── todo.tsx
├── next-env.d.ts
├── pages
│   ├── _app.tsx
│   └── index.tsx
└── tsconfig.json

Redux Structures

.
├── actions
│   └── index.ts
├── components
│   ├── page.tsx
│   └── todo.tsx
├── constants
│   └── actionTypes.ts
├── containers
│   └── page.tsx
├── reducers
│   ├── index.ts
│   └── todo.ts
├── selectors
│   └── index.ts
└── store.ts

Whole Structures

.
├── actions
│   └── index.ts
├── components
│   ├── page.tsx
│   └── todo.tsx
├── constants
│   └── actionTypes.ts
├── containers
│   └── page.tsx
├── next-env.d.ts
├── package.json
├── pages
│   ├── _app.tsx
│   └── index.tsx
├── reducers
│   ├── index.ts
│   └── todo.ts
├── selectors
│   └── index.ts
├── store.ts
└── tsconfig.json

Step 1: Hello World

$ mkdir test-app
$ cd test-app

After that, populate package.json and pages/index.tsx:

package.json

{
  "name": "test-app",
  "scripts": {
    "dev": "next"
  }
}

pages/index.tsx

export default () => <p>Hello World</p>;

And then, run the commands below:

# install dependencies
$ npm install --save next react react-dom
$ npm install --save-dev typescript @types/node @types/react @types/react-dom

# run as development mode
$ npm run dev

That's it!

Go to http://localhost:3000 and you'll see the Hello World!

Step 2: Build Redux TODO App (suddenly, I see)

I don't explain Redux architecture! lol

Just feel it, separation of the state and the view.

Define Features (ActionTypes and Actions)

Define the id of the action type in the constants/actionTypes.ts:

export const TODO_ONCHANGE = 'TODO_ONCHANGE';
export const TODO_ADD = 'TODO_ADD';
export const TODO_DELETE = 'TODO_DELETE';

And in the actions/index.ts, we define the callbacks to the reducers:

(Just define arguments and return data. Actions won't handle its state.)

import {
  TODO_ONCHANGE,
  TODO_ADD,
  TODO_DELETE,
} from '../constants/actionTypes';

export const onChangeTodo = (item) => ({ type: TODO_ONCHANGE, item });

export const addTodo = (item) => ({ type: TODO_ADD, item });

export const deleteTodo = (item) => ({ type: TODO_DELETE, item });

State Management (Reducers)

In the reducers/todo.ts, we define the initial state and how to handle it:

import {
  TODO_ONCHANGE,
  TODO_ADD,
  TODO_DELETE,
} from '../constants/actionTypes';

export const initialState = {
  // this is a TODO item which has one "value" property
  item: {
    value: '',
  },
  // this is a list of the TODO items
  data: [],
};

export default (state = initialState, action) => {
  // receive the type and item, which is defined in the `actions/index.ts`
  const {
    type,
    item,
  } = action;

  switch (type) {
    case TODO_ONCHANGE: {
      // BE CAREFUL!!!
      // DON'T USE THE REFERENCE LIKE THIS:
      //
      //     state.item = item;
      //     return state; // this `state` is "previous" state!
      //
      // Please create a new instance because that is a "next" state
      //
      return Object.assign({}, state, {
        item,
      });
    }

    case TODO_ADD: {
      // if the `item.value` is empty, return the "previous" state (skip)
      if (item.value === '') {
        return state;
      }

      return Object.assign({}, state, {
        // clear the `item.value`
        item: {
          value: '',
        },
        // create a new array instance and push the item
        data: [
          ...(state.data),
          item,
        ],
      });
    }

    case TODO_DELETE: {
      // don't use `state.data` directly
      const { data, ...restState } = state;

      // `[...data]` means a new instance of the `data` array
      // and filter them and remove the target TODO item
      const updated = [...data].filter(_item => _item.value !== item.value);

      return Object.assign({}, restState, {
        data: updated,
      });
    }

    // do nothing
    default: {
      return state;
    }
  }
};

And next, define reducers/index.ts which combines all reducers:

(currently only one reducer, yet)

import { combineReducers } from 'redux';
import todo, { initialState as todoState } from './todo';

export const initialState = {
  todo: todoState,
};

export default combineReducers({
  todo,
});

Create the Store

We define the one store so that we can access any states from the store.

And pass the store to the page: with the NEXT.js, pages/_app.tsx is one of the best choices.

store.ts

import thunkMiddleware from 'redux-thunk';
import {
  createStore,
  applyMiddleware,
  compose,
  Store as ReduxStore,
} from 'redux';
import { createLogger } from 'redux-logger';
import reducers, { initialState } from './reducers';

const dev: boolean = process.env.NODE_ENV !== 'production';

export type Store = ReduxStore<typeof initialState>;

export default (state = initialState): Store => {
  const middlewares = dev ? [thunkMiddleware, createLogger()] : [];
  return createStore(reducers, state, compose(applyMiddleware(...middlewares)));
};

pages/_app.tsx

import { NextPageContext } from 'next';
import App from 'next/app';
import withRedux from 'next-redux-wrapper';
import { Provider } from 'react-redux';
import store, { Store } from '../store';

interface AppContext extends NextPageContext {
  store: Store;
}

class MyApp extends App<AppContext> {
  render() {
    const { store, Component, ...props } = this.props;
    return (
      <Provider store={store}>
        <Component {...props} />
      </Provider>
    );
  }
}

export default withRedux(store)(MyApp);

Compose the Pages

First, define selectors to avoid deep nested state:

import { createSelector } from 'reselect';

export const selectState = () => state => state.todo;

export const selectTodoItem = () =>
  createSelector(
    selectState(),
    todo => todo.item,
  );

export const selectTodoData = () =>
  createSelector(
    selectState(),
    todo => todo.data,
  );

Second, use that selectors and pass them to the container with the actions:

containers/page.ts

import { connect } from 'react-redux';
import { createSelector } from 'reselect';
import {
  compose,
  pure,
} from 'recompose';
import {
  onChangeTodo,
  addTodo,
  deleteTodo,
} from '../actions';
import {
  selectTodoItem,
  selectTodoData,
} from '../selectors';
import Page from '../components/page';

export default compose(
  connect(
    createSelector(
      selectTodoItem(),
      selectTodoData(),
      (item, data) => ({ item, data }),
    ),
    {
      onChangeTodo,
      addTodo,
      deleteTodo,
    },
  ),
  pure,
)(Page);

Third, implement the page component:

components/page.tsx

import React from 'react';
import { compose } from 'recompose';
import Todo from './todo';

const Page = (props) => {
  // defined in the `containers/page.ts`, so the `props` is like this:
  //
  // const {
  //   item,
  //   data,
  //   onChangeTodo,
  //   addTodo,
  //   deleteTodo,
  // } = props;
  //
  return <Todo {...props} />;
};

export default compose()(Page);

Implement components/todo.tsx:

import React from 'react';
import { compose } from 'recompose';

const Todo= (props) => {
  const {
    item,
    data,
    onChangeTodo,
    addTodo,
    deleteTodo,
  } = props;

  return (
    <React.Fragment>
      <h1>TODO</h1>
      <form onSubmit={(e) => {
        e.preventDefault();
        addTodo({
          value: item.value,
        });
      }}>
        <input
          type="text"
          value={item.value}
          onChange={e => onChangeTodo({
            value: e.target.value,
          })}
        />
        <br />
        <input
          type="submit"
          value="SUBMIT"
          style={{
            display: 'none',
          }}
        />
      </form>
      <hr />
      {data.map((item, index) => (
        <p key={index}>
          {item.value}
          {' '}
          <button onClick={() => deleteTodo(item)}>
            DELETE
          </button>
        </p>
      ))}
    </React.Fragment>
  );
};

export default compose()(Todo);

Rewrite `pages/index.tsx`

Finally, update pages/index.tsx like this:

import {
  NextPageContext,
  NextComponentType,
} from 'next';
import { compose } from 'recompose';
import { connect } from 'react-redux';
import Page from '../containers/page';
import { addTodo } from '../actions';
import { Store } from '../store';

interface IndexPageContext extends NextPageContext {
  store: Store;
}

const IndexPage: NextComponentType<IndexPageContext> = compose()(Page);

IndexPage.getInitialProps = ({ store, req }) => {
  const isServer: boolean = !!req;

  // we can add any custom data here
  const { todo } = store.getState();
  store.dispatch(addTodo(Object.assign(todo.item, {
    value: 'Hello World!',
  })));

  return {
    isServer,
  };
}

export default connect()(IndexPage);

`TODO_ONCHANGE`:

`TODO_ADD`:

`TODO_DELETE`:

Conclusion

Practice makes perfect.

Thank you for your reading!

An Introduction of the Integration Library with NestJS and NEXT.js

Yoshihide Shiono — Thu, 10 Oct 2019 21:34:32 +0000

TLDR

In your controller like server/app.controller.ts:

import {
  Controller,
  Get,
  Req,
  Res,
} from '@nestjs/common';
import { NextService } from '@nestpress/next';

@Controller()
export class AppController {
  constructor(
    private readonly next: NextService,
  ) {}

  @Get()
  public async showIndexPage(@Req() req, @Res() res) {
    ///////////////////////////////////////////
    //                                       //
    //  this will render `pages/index.tsx`!  //
    //                                       //
    ///////////////////////////////////////////
    await this.next.render('/index', req, res);
  }
}

Why?

NestJS is a progressive Node.js framework, so we need to decide the view engine like handlebars.

I love to use React and sometimes want to get better SEO results when creating blogging system.

In that case, NEXT.js is a good choice.

But how do we use NEXT.js on top of NestJS?

NEXT.js is an SSR library, so it already includes the server which generates static html files.

And how do we pass the server data to the NEXT.js client dynamically?

Why and how are coming up to me, so I decided to write the integration library.

#showdev

(Be careful, the blogging system below is under construction! lol)

saltyshiomix / nestpress

A production ready personal blogging system on top of NestJS and NEXT.js

Roadmaps

Cross Platform
Dark Theme
Authentication
Blogging
Testing

Usage

Database Setup

For Mac Users

# install postgresql
$ brew install postgresql

# if you want to start postgresql in startup, try do this
$ brew services start postgresql

# create user "nestpressuser" with password "nestpresspass"
$ createuser -P nestpressuser

# create database "nestpressdb" owened by "nestpressuser"
$ createdb nestpressdb -O nestpressuser

For Windows Users

PostgreSQL

Download an installer at https://www.postgresql.org/download/windows
Run the installer with a flag --install_runtimes 0 like this:

> postgresql-11.2-1-windows-x64.exe --install_runtimes 0

pgAdmin

Download a latest installer at https://www.pgadmin.org/download
Run the pgAdmin and login with a root user
Right click Login/Group Roles and Create > Login/Group Role
- General Panel
  - Name: nestpressuser
- Definition Panel:
  - Password: nestpresspass
- Priviledges Panel:
  - Check all Yes
Right click Databases and Create > Database
- General Tab
  - Database: nestpressdb
  - Owner…

View on GitHub

And the core library is @nestpress/next.

In this article, I will introduce @nestpress/next and its usage.

Installation

$ npm install --save @nestpress/next

Usage

First, populate package.json, tsconfig.json and tsconfig.server.json:

package.json

{
  "name": "sample-app",
  "scripts": {
    "dev": "ts-node --project tsconfig.server.json server/main.ts",
    "build": "next build && tsc --project tsconfig.server.json",
    "start": "cross-env NODE_ENV=production node .next/production-server/main.js"
  },
  "dependencies": {
    "@nestjs/common": "latest",
    "@nestjs/core": "latest",
    "@nestpress/next": "latest",
    "next": "latest",
    "react": "latest",
    "react-dom": "latest",
    "reflect-metadata": "latest",
    "rxjs": "latest"
  },
  "devDependencies": {
    "@types/node": "latest",
    "@types/react": "latest",
    "@types/react-dom": "latest",
    "cross-env": "latest",
    "ts-node": "latest",
    "typescript": "latest"
  }
}

tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "jsx": "preserve",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "strict": true,
    "noEmit": true,
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "isolatedModules": true,
    "resolveJsonModule": true,
    "forceConsistentCasingInFileNames": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "incremental": true
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx"
  ],
  "exclude": [
    "node_modules"
  ]
}

tsconfig.server.json

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "module": "commonjs",
    "noEmit": false,
    "outDir": ".next/production-server"
  },
  "include": [
    "server"
  ]
}

Second, implement these files

NestJS side
- server/app.module.ts
- server/app.controller.ts
- server/main.ts
NEXT.js side
- pages/index.tsx

server/app.module.ts

import {
  Module,
  NestModule,
  MiddlewareConsumer,
  RequestMethod,
} from '@nestjs/common';
import {
  NextModule,
  NextMiddleware,
} from '@nestpress/next';
import { AppController } from './app.controller';

@Module({
  imports: [
    // register NextModule
    NextModule,
  ],
  controllers: [
    AppController,
  ],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    // handle scripts
    consumer
      .apply(NextMiddleware)
      .forRoutes({
        path: '_next*',
        method: RequestMethod.GET,
      });

    // handle other assets
    consumer
      .apply(NextMiddleware)
      .forRoutes({
        path: 'images/*',
        method: RequestMethod.GET,
      });

    consumer
      .apply(NextMiddleware)
      .forRoutes({
        path: 'favicon.ico',
        method: RequestMethod.GET,
      });
  }
}

server/app.controller.ts

Use NextService in your controllers like this:

import {
  IncomingMessage,
  ServerResponse,
} from 'http';
import {
  Controller,
  Get,
  Req,
  Res,
} from '@nestjs/common';
import { NextService } from '@nestpress/next';

@Controller()
export class AppController {
  constructor(
    private readonly next: NextService,
  ) {}

  @Get()
  public async showHome(@Req() req: IncomingMessage, @Res() res: ServerResponse) {
    // this will render `pages/index.tsx`!
    await this.next.render('/index', req, res);
  }
}

server/main.ts

Prepare the Next.js service in the main entry point:

import { NestFactory } from '@nestjs/core';
import { NextModule } from '@nestpress/next';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.get(NextModule).prepare().then(() => {
    app.listen(3000, 'localhost', () => {
      console.log('> Ready on http://localhost:3000 with Next.js!');
    });
  });
}

bootstrap();

pages/index.tsx

In the pages directory, we can do the same as the Next.js way:

export default () => (
  <p>Next.js on top of NestJS!</p>
);

Development Mode

$ yarn dev (or `npm run dev`)

Go to http://localhost:3000 and you'll see Next.js on top of NestJS!.

Production Mode

$ yarn build (or `npm run build`)
$ yarn start (or `npm start`)

Options

import { NestFactory } from '@nestjs/core';
import { NextModule } from '@nestpress/next';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.get(NextModule).prepare({
    /**
     * Whether to launch Next.js in dev mode
     */
    dev: process.env.NODE_ENV !== 'production',
    /**
     * Where the Next project is located
     */
    dir: process.cwd(),
    /**
     * Hide error messages containing server information
     */
    quiet: false,
    /**
     * Object what you would use in next.config.js
     */
    conf: {},
  }).then(() => {
    app.listen(3000, 'localhost', () => {
      console.log('> Ready on http://localhost:3000 with Next.js!');
    });
  });
}

bootstrap();

Advanced Usage: Pass the Server Data to the NEXT.js client

server/app.controller.ts

@Controller()
export class AppController {
  constructor(
    private readonly next: NextService,
    private readonly articleService: ArticleService,
  ) {}

  @Get()
  public async showHome(@Req() req: IncomingMessage, @Res() res: ServerResponse) {
    const articles = await this.articleService.findAll();
    const data = { articles };
    await this.next.render('/index', data, req, res);
  }
}

pages/index.tsx

import fetch from 'isomorphic-unfetch';

const HomePage = (props) => {
  const { articles } = props;

  return (
    <ul>
      {articles.map((article, index) => (
        <li key={index}>{article.title}</li>
      ))}
    </ul>
  );
};

// we must define `getInitialProps` so that the NEXT.js can generate static markups
HomePage.getInitialProps = async ({ req, query }) => {
  const isServer: boolean = !!req;

  let articles;
  if (isServer) {
    // in the NEXT.js server side, we can pass the server data
    // this `query.articles` is passed from AppController
    articles = query.articles;
  } else {
    // in the NEXT.js client side, we need to fetch the same data above
    const response = await fetch('http://localhost:3000/api/articles');
    articles = await response.json();
  }

  return {
    articles,
  };
};

export default HomePage;

Conclusion

The integration of NestJS and NEXT.js is a little tricky, but if we need to host React apps with SSR, I hope it helps you :)

Related Repository

saltyshiomix / ark

An easiest authentication system on top of NestJS, TypeORM, NEXT.js(v9.3) and Material UI(v4).

An easiest authentication system on top of NestJS, TypeORM, NEXT.js (v9) and Material UI (v4).

Features

Cross platform - Mac, Linux and Windows
Database synchronization with entities - powered by TypeORM
Server Side Rendering - powered by NEXT.js
API server - powered by NestJS
Authentication - powered by Passport
Material UI design

Technologies

Hot reloading for the developer experience :)
- ts-node-dev - Compiles your TS app and restarts when files are modified
- NEXT.js - The React Framework
Lang
- TypeScript - Javascript that scales
Database
- PostgreSQL - The World's Most Advanced Open Source Relational Database
ORM (Object-relational mapping)
- TypeORM - ORM for TypeScript and JavaScript (ES7, ES6, ES5)
Server
- NestJS - A progressive Node.js framework for building efficient, reliable and scalable server-side applications
  - internally using Express - Fast, unopinionated, minimalist web framework for Node.js
- NEXT.js - The React Framework
Environment variables
- dotenv - Loads environment variables from .env…

View on GitHub

A Guide for Upgrading macOS to Catalina and Migrating the Default Shell from Bash to Zsh

Yoshihide Shiono — Thu, 10 Oct 2019 09:29:14 +0000

Index

From Bash to Zsh
Configure Zsh
- Minimal Configuration
- Enable Git Completion
- Define Aliases
Prettify the Console with Starship 🚀

From Bash to Zsh

After upgrading macOS to Catalina (lol), the command below changes the default shell to zsh:

$ chsh -s /bin/zsh

That's it!

Configure Zsh

Minimal Configuration

To configure zsh, just populate ~/.zshrc like this:

# enable the default zsh completions!
autoload -Uz compinit && compinit

Enable Git Completion

To enable git completion, try commands below:

# make the `.zsh` directory
$ mkdir -p ~/.zsh
$ cd ~/.zsh

# download the scripts for completion
$ curl -o git-completion.bash https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash
$ curl -o _git https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.zsh

After that, we can load the scripts in the ~/.zshrc:

zstyle ':completion:*:*:git:*' script ~/.zsh/git-completion.bash
fpath=(~/.zsh $fpath)

Finally, remove the cache:

$ rm ~/.zcompdump

Define Aliases

My favorite and minimal aliases are:

alias ..='cd ..'
alias ...='cd ../..'
alias ls='ls -GwF'
alias ll='ls -alh'

Yes ll is not defined when using zsh.

And if we use VSCode, we can edit ~/.zshrc by running the command zshrc:

alias zshrc='code ~/.zshrc'

In the same way, to edit ~/.gitconfig by the command gitconfig, add the line below in the ~/.zshrc:

alias gitconfig='code ~/.gitconfig'

Prettify the Console with Starship 🚀

Do you know starship?

TLDR, see my pretty console :)

I love this console! lol

Installation

$ brew install starship

And add the init script to the end of ~/.zshrc:

eval "$(starship init zsh)"

Configuration

For full information, please see the documentation.

My minimal configuration as a TypeScript developer, a cat lover and a basketball enthusiast is:

# in `~/.config/starship.toml`

[character]
symbol = "🐈💕"

[directory]
fish_style_pwd_dir_length = 10

[git_branch]
symbol = "🏀 "

[nodejs]
symbol = "⚡ "

[package]
symbol = "🎉 "

symbol	why or what
🐈💕	just so cute - nyaaan in Japanese / meow in English
🏀 master	git branch
⚡ v12.11.1	nodejs version
🎉 v6.6.0	package version

Conclusion

No console, no developers :)

The Power of Flexible Types in TypeScript

Yoshihide Shiono — Wed, 02 Oct 2019 04:00:01 +0000

There are so many advantages of TypeScript than JavaScript.

In this article, I will introduce my love-to-use TypeScript use cases.

Index

Union Types
any Type
Overloads are Awesome

Union Types

Flexible String Union Types

// accept all strings
const name: string = 'anyone';

// stricted to string "john"
const john: 'john' = 'someone'; // type error

// union type (only "john" and "michael" are accepted)
const men: 'john' | 'michael' = 'smith'; // type error

Flexible Union Interfaces

interface OptionA {
  value: 'A';
  funcOnlyOptionA: () => void;
}

interface OptionOthers {
  value: Omit<string, 'A'>;
  funcOptionOthers: () => void;
}

Omit<T, U> is a TypeScript built-in type and it excludes U from T.

// no error
const option1: OptionA | OptionOthers = {
  value: 'A',
  funcOnlyOptionA: () => console.log('Hello Interface A'),
};

// no error
const option2: OptionA | OptionOthers = {
  value: 'B',
  funcOptionOthers: () => console.log('Hello String (without "A")'),
};

// NO ERROR!
// because this is a `union` type
const option3: OptionA | OptionOthers = {
  value: 'A',
  funcOptionOthers: () => console.log('Hello String (without "A")'),
};

But, how to compare option1 and option2?

In other words, how to get type errors in the case of option3?

Let's get into deeper:

const isOptionA = (option: any): option is OptionA => {
  return (option as OptionA).value === 'A';
};

const option: OptionA | OptionOthers = generateOption();

if (isOptionA(option)) {
  // now `option` is casted to `OptionA` automatically

  // good
  option.funcOptionA();

  // type error!
  option.funcOptionOthers();
}

`any` Type

Naturally, Types are Checked Automatically

interface User {
  name: string;
}

const user: User = { name: 'John' };

const updatedUser: User = {
  ...user,
  name: 'New John', // no errors
  bio: 'I am something!', // type error!
};

// but if we use `any` type, we can't get the benefit above:

const person = { name: 'Alex' }; // `person` is `any` type

const updatedPerson = {
  ...person,
  name: 'AlexxX', // no errors
  bio: 'I am a hacker', // no errors!
};

`any` Type can Convert ANY Types

See a simple example here:

interface User {
  name: string;
}

const possiblyUserObject: any = {};

const typedUser: User = possiblyUserObject; // no errors

console.log(typedUser.name); // undefined

It seems natural enough and there is nothing to study. lol

Anything else? Sure.

We can Convert JSON Object to the User Defined Types

Consider that we will fetch user data from a server. We may define the http client like this way:

(by using a http library named ky)

import ky from 'ky-universal';

const prefixUrl: string = 'http://localhost';

export class Http {
  public async get(url: string) {
    return ky.get(url, { prefixUrl }).json();
  }

  public async post(url: string, data?: any) {
    return ky.post(url, { prefixUrl, json: data }).json();
  }

  public async put(url: string, data?: any) {
    return ky.put(url, { prefixUrl, json: data }).json();
  }

  public async delete(url: string) {
    return ky.delete(url, { prefixUrl }).json();
  }
}

And we can use this Http class like below:

const http = new Http();

const user = await http.get('api/user/1');

console.log(user.name); // no errors, because `user` is `any` type

Yes it works perfectly, but we can't get benefit from TypeScript.

So let's rewrite Http class with TypeScript generics:

import ky from 'ky-universal';

const prefixUrl: string = 'http://localhost';

export class Http {
  // because json is `any` type, so we can cast it to the generic type `T`
  public async get<T>(url: string): Promise<T> {
    return ky.get(url, { prefixUrl }).json();
  }

  public async post<T>(url: string, data?: any): Promise<T> {
    return ky.post(url, { prefixUrl, json: data }).json();
  }

  public async put<T>(url: string, data?: any): Promise<T> {
    return ky.put(url, { prefixUrl, json: data }).json();
  }

  public async delete<T>(url: string): Promise<T> {
    return ky.delete(url, { prefixUrl }).json();
  }
}

And finally we can get intellisense (code complete, auto correct and so on) from your IDE like editors such as VSCode:

const http = new Http();

const user = await http.get<User>('api/user/1');
// or:
// const user: User = await http.get('api/user/1'); // no errors!

console.log(user.name); // this user is the type `User`!

Overloads are Awesome

JavaScript can't create overloads as far as I know.

If we fetch user data by id or ids, the source code is something like this:

// JavaScript

function fetchData(id) {
  if (Array.isArray(id)) {
    return [
      { name: 'john' },
      { name: 'alex' },
    ];
  }
  return { name: 'john' };
}

const data1 = fetchData(1);
console.log(data1.name); // john

const data2 = fetchData([1, 2]);
console.log(data2[0].name); // john

// but, if `id` is object, we must check the return data is array or not:
const data3 = fetchData(idOrIds);
if (Array.isArray(data3)) {
  // data3 is users
} else {
  // data3 is user
}

On the other hand, it is possible to create overloads in TypeScript:

// define overloads!
function fetchData(id: number): User
function fetchData(ids: number[]): User[]

// implementation!
function fetchData(id: number | number[]): User | User[] {
  if (Array.isArray(id)) {
    return [
      { name: 'john' },
      { name: 'alex' },
    ];
  } else {
    return { name: 'john' };
  }
}

const data1 = fetchData(1);
console.log(data1.name); // john (no errors! awesome!)

const data2 = fetchData([1, 2]);
console.log(data2[0].name); // john (no errors! awesome!)

The React View Template Engine for Express

Yoshihide Shiono — Tue, 24 Sep 2019 19:01:33 +0000

TLDR

Pass the server data to the React client props
Because this is a view template engine, so results can be searchable by searching engines like Google (yes, we use server side rendering)

saltyshiomix / react-ssr

React SSR as a view template engine

Overview

SSR (Server Side Rendering) as a view template engine
Dynamic props
- Passing the server data to the React client props
- Suitable for
  - Admin Panels
  - Blogging
Developer Experience
- Zero config of webpack and babel
- HMR (Hot Module Replacement) both scripts and even if styles when process.env.NODE_ENV !== 'production'
- Built-in Sass (SCSS) support

Pros and Cons

Pros

Because it is just a view template engine:

It doesn't need to have any APIs, all we have to do is to pass the server data to the client
It supports multiple engines like .hbs, .ejs and React .(ts|js)x
We can use passport authentication as it always is

Cons

It is not so performant, because it assembles the whole HTML on each request
It does not support client side routing

Usage

With @react-ssr/express

Install it:

$ npm install --save @react-ssr/core @react-ssr/express express react react-dom

And add a script to your package.json like this:

…

View on GitHub

Quick Start

Installation

$ npm install --save @react-ssr/express express react react-dom

Populate `package.json`

{
  "scripts": {
    "start": "node server.js"
  }
}

Write `server.js`

const express = require('@react-ssr/express');
const app = express();

app.get('/', (req, res) => {
  const user = { name: 'World' };
  res.render('index', { user });
});

app.listen(3000, () => {
  console.log('> Ready on http://localhost:3000');
});

Implement `views/index.jsx`

import React from 'react';

export default function Index(props) {
  return `Hello ${props.user.name}!`;
}

Run Server

$ npm start

You'll see Hello World!

Deep into Dive

1. Register `jsx` and `tsx`

source: register.ts

const ENGINE: 'jsx' | 'tsx' = getEngine();
app.engine(ENGINE, renderFile);
app.set('views', resolve(process.cwd(), viewsDir));
app.set('view engine', ENGINE);
app.use(express.static(distDir));

2. Render a File (Server Side Rendering)

source: render.tsx

import { renderToString } from 'react-dom/server';

let html: string = '<!DOCTYPE html>';

let Page = require(file); // `file` is a React function component
Page = Page.default || Page;

html += renderToString(
  <Html script={`${hash}.js`}>
    <Page {...props} />
  </Html>
);

return html;

3. Bundle Scripts and Write Output

source: render.tsx

import fs from 'fs';
import template from 'art-template';
import webpack from 'webpack';

const { ufs } = require('unionfs');
const MemoryFileSystem = require('memory-fs');
const template = require('art-template');

const cwd: string = process.cwd();

template.defaults.minimize = false;

const mfs = new MemoryFileSystem;
ufs.use(mfs).use(fs); // union memory-fs and fs!

// write file in the server memory
mfs.mkdirpSync(resolve(cwd, 'react-ssr-src'));
mfs.writeFileSync(resolve(cwd, `react-ssr-src/entry.jsx`), template(resolve(__dirname, '../page.jsx'), { props }));
mfs.writeFileSync(resolve(cwd, `react-ssr-src/page.jsx`), template(file, props));

// compile in the server memory!
const compiler: webpack.Compiler = webpack(configure(hash, ext, distDir));
compiler.inputFileSystem = ufs;
compiler.outputFileSystem = mfs;
compiler.run((err: any) => {
  if (err) {
    console.error(err.stack || err);
    if (err.details) {
      console.error(err.details);
    }
    return;
  }
});

// read the results from memory file system
// write the results to the real file system
await outputFileSync('result.js', mfs.readFileSync(cache).toString());

That's it!

Final output html is like this:

<!DOCTYPE html>
<html>
  <body>
    <div id="app">
      <p>Hello World!</p>
    </div>
    <script src="/c834ab9b47260a08d695f59ba1a5b24d.js"></script>
  </body>
</html>

Ending

But I love to use NEXT.js! lol

Nextron v4 : Electron + Next.js with ease

Yoshihide Shiono — Mon, 11 Feb 2019 11:50:20 +0000

Today zeit released Next.js v8, so Nextron came to v4 :)

https://nextjs.org/blog/next-8

What is Nextron?

Nextron is an electron app generator, which includes Next.js and it can handle electron renderer process with Next.js easily.

# install nextron
$ npm install --global nextron@latest

There are 13 example templates for now:

# list all templates
$ nextron list

  Available examples:

    - custom-build-options
    - custom-server
    - custom-server-nodemon
    - custom-server-typescript
    - ipc-communication
    - parameterized-routing
    - store-data
    - with-javascript
    - with-javascript-ant-design
    - with-javascript-material-ui
    - with-typescript
    - with-typescript-less
    - with-typescript-material-ui

  USAGE

    $ nextron init my-app [--template example_folder_name]

  If you want to use "with-typescript-material-ui", just type the command below:

    $ nextron init my-app --template with-typescript-material-ui

The usage is so simple:

# generate an example
$ nextron init my-app --template with-typescript-material-ui

# install dependencies
$ cd my-app
$ yarn (or "npm install")

# development mode
$ yarn dev (or "npm run dev")

# production build
$ yarn build (or "npm run build")

My Belief for Nextron

Show a way of developing desktop apps only web knowledge
- always maintenanced 👍
Easy to use
- run it one command
- build it one command
Be transparent (Open to OSS developers)
- shows all sources like webpack.config.js, electron production build configs and so on

Nextron's statuses

650+ commits over the last 9 months
200+ releases (npm publish)
100+ stargazers on GitHub
listed on awesome-nextjs
PRs are welcome!

By the way...

I'm working in Tokyo(Japan) and developing .NET or JavaScript(TypeScript) apps which use AI(neural network) translation machine.

Our mission is to help all people who study foreign languages.

Anyone want to join us?

Thank you for your reading my article :)

A road to the easiest user authentication system for Node.js

Yoshihide Shiono — Sat, 15 Dec 2018 11:22:35 +0000

JavaScript is easy to read and write, but sometimes we are facing difficulties like user authentication.

Before talking about user authentication deeper, let me introduce you what I made this weekend:

saltyshiomix / ark

An easiest authentication system on top of NestJS, TypeORM, NEXT.js(v9.3) and Material UI(v4).

An easiest authentication system on top of NestJS, TypeORM, NEXT.js (v9) and Material UI (v4).

Features

Cross platform - Mac, Linux and Windows
Database synchronization with entities - powered by TypeORM
Server Side Rendering - powered by NEXT.js
API server - powered by NestJS
Authentication - powered by Passport
Material UI design

Technologies

Hot reloading for the developer experience :)
- ts-node-dev - Compiles your TS app and restarts when files are modified
- NEXT.js - The React Framework
Lang
- TypeScript - Javascript that scales
Database
- PostgreSQL - The World's Most Advanced Open Source Relational Database
ORM (Object-relational mapping)
- TypeORM - ORM for TypeScript and JavaScript (ES7, ES6, ES5)
Server
- NestJS - A progressive Node.js framework for building efficient, reliable and scalable server-side applications
  - internally using Express - Fast, unopinionated, minimalist web framework for Node.js
- NEXT.js - The React Framework
Environment variables
- dotenv - Loads environment variables from .env…

View on GitHub

Yes, this is a super duper simple user authentication system :)

On the other hand, it uses these technologies:

Hot reloading for the developer experience :)
- nodemon - Monitor for any changes in your node.js application and automatically restart the server
- Next.js - The React Framework
Lang
- TypeScript - Javascript that scales
Database
- PostgreSQL - The World's Most Advanced Open Source Relational Database
ORM (Object-relational mapping)
- TypeORM - ORM for TypeScript and JavaScript (ES7, ES6, ES5)
Server
- nest - A progressive Node.js framework for building efficient, reliable and scalable server-side applications
  - internally using Express - Fast, unopinionated, minimalist web framework for Node.js
- Next.js - The React Framework
Environment variables
- dotenv - Loads environment variables from .env for nodejs projects
User authentication
- Passport - Simple, unobtrusive authentication for Node.js
UI framework
- React - A JavaScript library for building user interfaces
- Next.js - The React Framework
- Material UI - React components that implement Google's Material Design.

So many libraries, right? Easiest authentication?

Yes.

Let's digging deeper:

Fun Database

Thanks to TypeORM, we can synchronize database with entities.

Here is a user.entity.ts:

import {
  Entity,
  Column,
  PrimaryGeneratedColumn
} from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column('varchar')
  name: string;

  @Column('varchar', {
    unique: true
  })
  email: string;

  @Column('varchar')
  password: string;  
}

TypeORM automatically synchronize database from @Entity() decorator information.
In other words, database automatically changes as soon as you save user.entity.ts.

Fun Coding

With nest, we can use modern JavaScript(TypeScript), and with VSCode we can obtain the maximum benefit like code intelligence.

Here is a sample users.controller.ts:

import {
  Controller,
  Get
} from '@nestjs/common';
import { User } from './user.entity';
import { UsersService } from './users.service';

@Controller('api/users')
export class UsersController {
  constructor(private readonly service: UsersService) {}

  @Get()
  async findAll(@Query() query): Promise<User[]> {
    return await this.service.findAll();
  }
}

By constructor injection, users.controller.ts doesn't care about how to findAll() users.

And users.service.ts is like this:

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(@InjectRepository(User) private readonly repository: Repository<User>) {}

  async findAll(): Promise<User[]> {
    return await this.repository.find();
  }
}

Can you believe this?

We can findAll() users without coding SQL scripts because TypeORM and nest conceal implementation. (so called "Repository Pattern")

Fun SEO (Server Side Rendering)

Next.js enables us to write page/index.tsx without caring about server side rendering:

export default () => 'Hello SSR!'; // this is a React.Component :)

How to try ARK

First, you need to install PostgreSQL.

If you use Mac and Homebrew, setup is so easy:

# install database (postgresql)
$ brew install postgresql

# if you want to start postgresql in startup, try do this
$ brew services start postgresql

# create user "arkuser" with password "arkark"
$ createuser -P arkuser

# create database "arkdb" owened by "arkuser"
$ createdb arkdb -O arkuser

That's it!

And use it like Next.js:

# clone repository
$ git clone https://github.com/saltyshiomix/ark.git

# install dependencies
$ cd ark
$ yarn

# development mode
# please make sure to create the `.env` file!
$ yarn dev

# production mode
# please make sure to create the `.next/.env` file!
$ yarn build
$ yarn start

(.env file is like this:)

# DB
DB_TYPE=postgres
DB_HOST=localhost
DB_PORT=5432
DB_USERNAME=arkuser
DB_PASSWORD=arkark
DB_DATABASE=arkdb
DB_SYNCHRONIZE=true

# App
HOST=localhost
PORT=4000
SESSION_SECRET=ark

And you'll see http://localhost:4000:

And create an account:

You are now logged in!

Conclusion

I created ARK repository for the purpose of showing how to implement user authentication system easily.

So PRs are welcome!
(like "Implement social login", "Implement JSON API" and so on.)

I hope you helped :)

DEV Community: Yoshihide Shiono

Upgrading to Serverless Framework v4: The Why and the How

Self-Introduction

What is the Serverless Framework?

Differences between Serverless Framework v3 and v4

Licensing Changes

Authentication required for every serverless command

Focus on AWS Lambda support going forward

Native TypeScript Support

Why we're gradually entering the era of Serverless Framework v4 (whether we like it or not)

Node.js v22 (LTS) doesn't run on Serverless Framework v3

Ecosystem plugins are being absorbed into Serverless Framework v4

Example using esbuild in Serverless Framework v3

Example using esbuild in Serverless Framework v4

How to run Serverless Framework v4 in GitHub Actions

Running in GitHub Actions without serverless login

If it works locally but not in GitHub Actions

Summary

Saying Goodbye to Husky: How Lefthook Supercharged Our TypeScript Workflow

Introduction: The Unseen Impact of Git Hooks on DX

The Limits of the Past: Why Husky + lint-staged Can Feel "Heavy"

① Node.js Runtime Overhead

② Sequential Execution Bottlenecks

③ Scattered Configuration

Enter Lefthook: The Next-Gen Choice

The Migration Guide: From Husky to Lefthook

STEP 1: The Cleanup

STEP 2: Install and Initialize Lefthook

STEP 3: Designing your lefthook.yml

Why Parallel Matters

Advanced Techniques for the Real World

① Mastering Monorepos

② Emergency Skips

③ Personal Overrides with lefthook-local.yml

Closing Thoughts: Better DX, One Commit at a Time

LGTMify - An LGTM generator (Chrome Extension)

Motivation

How to Use

GitHub repository

Introducing an Alternative to NEXT.js

Introduction

Let's Imagine!

About react-ssr

saltyshiomix / react-ssr

React SSR as a view template engine

Overview

Pros and Cons

Pros

Cons

Usage

With @react-ssr/express

Overview

How to Use react-ssr

Usage of @react-ssr/express in JavaScript

Usage of @react-ssr/express in TypeScript

Usage of @react-ssr/nestjs-express

There Are Many Examples

examples/with-jsx-antd

examples/with-jsx-emotion

examples/with-jsx-material-ui

examples/with-jsx-semantic-ui

examples/with-jsx-styled-components

Conclusion

[Express] React as a View Template Engine?

Updated (2019/10/29)

Intro

Imagine This!

package.json

server.js

views/index.jsx

Please Try This! And Tell Me Your First Impression!

saltyshiomix / react-ssr-jsx-starter

An example of @react-ssr/express

Usage

Related

About @react-ssr/express

saltyshiomix / react-ssr

React SSR as a view template engine

Overview

Pros and Cons

Authentication required for every `serverless` command

Running in GitHub Actions without `serverless login`

STEP 3: Designing your `lefthook.yml`

③ Personal Overrides with `lefthook-local.yml`

About `react-ssr`

How to Use `react-ssr`

Usage of `@react-ssr/express` in JavaScript

Usage of `@react-ssr/express` in TypeScript

Usage of `@react-ssr/nestjs-express`

`examples/with-jsx-antd`

`examples/with-jsx-emotion`

`examples/with-jsx-material-ui`

`examples/with-jsx-semantic-ui`

`examples/with-jsx-styled-components`

Rewrite `pages/index.tsx`

`TODO_ONCHANGE`:

`TODO_ADD`:

`TODO_DELETE`: