DEV Community: Felix Haus

Create your own serverless image optimizer for Next.js in 5 minutes

Felix Haus — Sat, 01 May 2021 15:48:34 +0000

With the introduction of Next.js 10 the new next/image component was added. It is a modern approach to enhance the <img> HTML-Element by adjusting the image based on the viewer’s needs. By recognizing what image extensions (e.g. newer formats like WebP) the client browser supports, it converts the source accordingly and also resizes the image optimized for the screen width of the viewer.

The optimization itself is performed on the fly when the resource is requested by the user. This makes the solution perfectly scalable whether it is used for 10 or 10 million images.

But what if you self-host your app as a single server or inside a docker container? Spinning up more instances just to deal with the increased traffic caused by image processing can be pretty expensive.

Fortunately the Next.js developers have a solution for this: You can use a cloud-based external image loader to perform this task. Currently Imgix, Cloudinary and Akamai are officially supported.

Since we were already using Amazon Web Services (AWS) we thought about how we could bring this service directly to their platform without relying on third-party cloud services. The basic idea was to isolate the part from Next.js core responsible for the image optimization, pack it into a serverless function (AWS Lambda) and use it as an external loader.

Serverless AWS stack for image optimization with Next.js

This way we would be able to achieve full support of all next/image features and a maximum of scalability because AWS Lambda can scale up and down dynamically to met the demand.
Since we do not want to run the serverless function on every request we put it behind a CloudFront distribution that is able to serve recurring requests for the same resources from cache. It also makes the whole thing noticeably faster since CloudFront CDN network is able to store the cache close the viewers location.

Because we are already manage most of our DevOps stack with Terraform, we also used it to create the image optimizer. This also makes it possible to share the whole module so that it can easily be reused.

Deploy the serverless image optimizer to AWS

All you need to create your own image optimizer in 5 minutes is an AWS account and Terraform installed.

Then create a new file called main.tf (Can be added to the same directory as your Next.js app), which contains the definition and configuration of the module:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

# Main AWS region where the resources should be created in
# Should be close to where your Next.js deployment is located
provider "aws" {
  region = "us-east-1"
}

module "next_image_optimizer" {
  source = "milliHQ/next-js-image-optimization/aws"

  next_image_domains = ["example.com", "sub.example.com"]
}

output "domain" {
  value = module.next_image_optimizer.cloudfront_domain_name
}

The next_image_domains variable should contain the domains where the external images should be fetched from. It takes the same configuration as the Domains setting from Next.js.

After that you are all set to deploy the module to your AWS account. All you need to do is running the two Terraform commands:

terraform init
terraform apply

After Terraform has finished deploying the module, it shows you the following output on the Terminal:

Apply complete!

Outputs:

domain = "<distribution-id>.cloudfront.net"

The domain of the CloudFront distribution ("<distribution-id.cloudfront.net") is all you need to tell your Next.js app to use the newly created image optimizer. Open or create your next.config.js and add the following lines:

module.exports = {
+  images: {
+    path: 'https://<distribution-id>.cloudfront.net/_next/image'
+  },
}

Last step is now to redeploy your Next.js app with the changed configuration. Now you are using your own, self-hosted image optimizer.

You can take look at the source code of the module on GitHub, since everything is Open Source:

milliHQ / terraform-aws-next-js-image-optimization

A drop-in image optimization loader for Next.js image component powered by AWS Lambda.

Terraform Next.js Image Optimization module for AWS

A drop-in image optimization loader for the Next.js image component next/image.

Notice: If you look for a complete solution to host a Next.js application with Terraform on AWS, please check out our Terraform Next.js module for AWS.

Features

✅ Terraform v0.13+
✅ Serverless image processing powered by AWS Lambda
✅ Powerful optimization using the sharp processing library
✅ Performant image caching powered by Amazon CloudFront
✅ Two-layer caching with CloudFront Origin Shield
✅ Support for custom Device Sizes & Image Sizes

Architecture

The image optimization module is designed as a full stack AWS app. It relies on multiple AWS services and connects them to work as a single application:

Usage

1. Deploy the module to AWS

Initialize the module by creating a main.tf file with the following content (you can place the file in the same directory where your Next.js project…

View on GitHub

Looking for a full stack solution to deploy Next.js on AWS?

If you don't want to mess around with configuration and want a complete solution to host Next.js serverless on AWS, please checkout our Terraform Next.js module for AWS. It has image optimization already built in and can handle most features from Next.js in a cost-efficient way.

Why we self-host our serverless Next.js site on AWS with Terraform

Felix Haus — Sat, 09 Jan 2021 15:46:39 +0000

Last summer we had the idea to publish our Next.js site serverless on Amazon Web Services (AWS). Because we live in Germany and Vercel only supports a few of AWS regions for deploying your site in Europe (closest to Germany is Paris/France) we began a search how we could deploy our website to the AWS Frankfurt region.

TL;DR

We didn't want to rely on a cloud service (Serverless Components or Vercel) for deploying our application

Deploying our app should require nearly zero-config and support all major Next.js features

We created an Open Source Terraform module for doing it: https://github.com/milliHQ/terraform-aws-next-js

How-to tutorial at the end of the article: Deploy Next.js to AWS

By the time there were only a few choices for doing that and the most promising of them was the serverless-next.js project that is based on the Serverless Framework. By this time Serverless announced a new product called Serverless Components. While it was introduced as a simpler way to deploy applications based on cloud functions, they also changed the way the deployment works: Instead of bundling and uploading it directly from your machine, you now had to use their cloud service, upload the source there and the Serverless cloud would then build and provision your app on AWS.

While this concept isn’t something really new (Vercel does it the same way) we kept searching for a another way without relying on cloud services to build our app and risk a vendor lock-in.

That time we also began using Terraform to manage our existing resources on AWS (Like domains, Static files on S3 buckets, CloudFront distributions, etc.). Terraform is an Open-Source tool by HashiCorp for creating a code-based abstraction of your cloud resources and services (Similar to CloudFormation but not limited to AWS, since their open provider concept allows to manage resources even across multiple cloud providers).

Becoming independent

While transitioning some of our infrastructure to Terraform we draw a few diagrams of our existing AWS services to define how they are connected with each other (e.g. which CloudFront distribution should be served from which S3 bucket). This is a really powerful concept in Terraform: You don't just say which resources and services you want to create, you can also connect them with code-based rules.

At one time we drew a diagram of how a serverless architecture of our site with pure AWS services would look like:

The architecture of our serverless Next.js deployment

The idea was simple: Zero config in our Next.js app and let Terraform do the heavy lifting deploying our site to AWS.

While it is relatively easy to do static hosting with Next.js on a S3 bucket and a CloudFront distribution, it is a bit more difficult to include server-side rendering (SSR) in this stack. CloudFront is the CDN service from AWS that allows you to distribute static content like HTML, JavaScript or images in edge locations near your visitors so that following requests can be cached without hitting the origin resources. This way a site can be served with pretty low latency to customers around the globe while only paying a fraction of the costs that a request to the origin resource would cost.

While CloudFront is good for reducing the load time of the site, it also offers a service called Lambda@Edge that allows us to run server-side code in these edge locations.
This is a major key where our architecture is different from the serverless-next.js component: Serverless uses these Lambda@Edge functions to generate the SSR content while we only use it to determine from which origin the content should be served.

Understanding the Next.js routing

Next.js has a built-in router called next/router. The router is designed to work both on the client and the server side. In local development they work pretty similar on each side but when exporting the site to a serverless architecture the app gets splitted into different parts:

Static assets (e.g. JavaScript, CSS, Images)

These are files that have a hashed filename (like some.chunk.14f293g29.js) and are not modified over time. Instead they get a new name when a new deployment is made.
Static routes

Static routes are the ones that do not use parameters in their path (e.g. example.com/about) and do not call getServerSideProps(). These routes are pre-rendered at build time and packaged as static HTML files. So these routes can only be modified by a new deployment of the site.
Dynamic routes

Dynamic routes in Next.js need a server to render the corresponding HTML. That includes pages that are dynamically rendered (e.g. with data from a database) or use a dynamic parameter in their path (example.com/blog/[postId]) where the final paths could not be calculated at build time.

Since the static routes should not trigger a server (in our case the AWS Lambda function), we need to find a way to split the static and dynamic traffic before it hits the server.

This is very simple for static assets, since all of their paths begin with /_next/static/... so we can create a simple CacheBehavior in CloudFront that looks for this prefix and redirect all requests for them to a S3 bucket where we uploaded our assets.

For static and dynamic routes this is more complicated: Since a request for a static site looks exactly the same as for a dynamic route (e.g. example.com/about, example.com/blog/123) we need a custom logic that can decide if the route is static or whether it should be server-rendered by a Lambda.

To accomplish this task we created a custom component called Proxy which is simply a serverless Node.js function that is able to determine where a route should be served from. Since this proxy is a crucial part for the performance of the site it is deployed directly at the CloudFront edge locations with Lambda@Edge.

This is a trade-off we make here because running code in Lambda@Edge is three times more expensive than running the code in regional Lambdas. So we paid attention that the code for the proxy has as few dependencies as possible and can be executed really fast once the Lambda is warmed up.

We built the proxy logic so that it behaves in the same way as Vercel does with their routing configuration. This way we ensured a maximum of compatibility with the way Vercel does deployments and were able to recreate features for Next.js that they offer.

Preparing Next.js for a serverless environment

It seems strange at first that we need that much effort to make Next.js serverless because seeing it running on Vercel so smoothly, you may think it is a native serverless application.

That’s wrong. Next.js at its core is simply a Node.js webserver and even on Vercel it runs as a server rather than a serverless function. The trick here is to convert the invoke event from the cloud function to a HTTP server request and then parse the HTTP server response back to a callback parameter of the function:

The flow of a request to a serverless Next.js site

In AWS Lambda with JavaScript you can simply achieve this by starting a local HTTP server for each invocation and then create a client request to get the server response like this:

// Reference implementation how to start a Next.js webserver inside a Lambda
// from API Gateway invocation
// https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html

const { request } = require('http');

// Import the generated Next.js server from somewhere
const NextServer = require('./dist');

exports.handler = async function (event) {
  // Deconstruct API Gateway event
  const {
    http: { method, path },
  } = event.requestContext;

  // Start local server and get address once it's running
  const address = await new Promise((resolve) => {
    const server = new NextServer();

    server.listen(
      {
        host: '127.0.0.1',
        port: 0,
      },
      function listeningCallback() {
        const addr = this.address();
        resolve(addr);
      }
    );
  });

  const payload = await new Promise((resolve, reject) => {
    request(
      {
        hostname: '127.0.0.1',
        port: address.port,
        path,
        method,
      },
      (res) => {
        const respBodyChunks = [];
        res.on('data', (chunk) => respBodyChunks.push(Buffer.from(chunk)));
        res.on('error', reject);
        res.on('end', () => {
          const bodyBuffer = Buffer.concat(respBodyChunks);
          resolve({
            statusCode: response.statusCode || 200,
            headers: response.headers,
            body: bodyBuffer.toString('base64'),
            isBase64Encoded: true,
          });
        });
      }
    );
  });

  return payload;
};

Over time there emerged multiple solutions for doing this but all of them require a lot of additional configuration to make it work. Since our goal was to require as little configuration as possible, we took a closer look how Vercel achieved this.

What makes Vercel a really outstanding company is that they open sourced a lot of their internal tooling. They use a package called now-next that does the packaging of Next.js before it gets deployed to their infrastructure (The name “now” comes from the time the company was named Zeit, which means “Time” in German, which was a pretty great naming in my opinion, since I am German too 😊).

Because the routing logic of our proxy component reproduces the behavior of the Vercel proxy it was now pretty easy for us to make the output from their builder to work with our architecture.

This way we achieved a similar developer experience that Vercel has while running the whole build and deployment process on our own machine.

Deploy Next.js to AWS

Okay, we talked a lot about why and how we built the architecture the way it is, now it is time to show you the whole thing. Because we profited a lot of Open Source in this project and in the past, we decided to make the module publicly available too:

milliHQ / terraform-aws-next-js

Terraform module for building and deploying Next.js apps to AWS. Supports SSR (Lambda), Static (S3) and API (Lambda) pages.

Note
The main branch currently contains the atomic deployments alpha preview
For the lastest stable release, check out the v0.x branch

Please see our blog post "The road to Atomic Deployments"
or watch the latest release review for more information

Terraform Next.js module for AWS

A zero-config Terraform module for self-hosting Next.js sites serverless on AWS Lambda.

Features

Some features are still under development, here is a list of features that are currently supported and what we plan to bring with the next releases:

✅ Supports any version of Next.js
✅ Terraform v0.15+
✅ Unlimited parallel deployments of Next.js apps (atomic deployments)
✅ Static, SSG, Lambda and API pages (with dynamic routes)
✅ Automatic expiration of old static assets
✅ Rewrites & Redirects
✅ Image Component & Image Optimization support
🚧 Incremental Static Regeneration
⛔️ Middleware (Not supported by Lambda@Edge / CloudFront functions)

Architecture

The Next.js Terraform module…

View on GitHub

Installation and deployment can be broken down to a few easy steps, so if you have a minute left to spend, here is how you can deploy your own Next.js app to AWS:

Prerequisites

Make sure you have Terraform installed.
Create AWS Access Keys (Access Key ID & Secret Access Key) from an AWS Account with admin privileges.
Create a new file in the root directory of your Next.js project called main.tf with the following content:

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

# Main region where the resources should be created in
provider "aws" {
  region = "us-east-1"
}

module "tf_next" {
  source = "milliHQ/next-js/aws"
}

output "cloudfront_domain_name" {
  value = module.tf_next.cloudfront_domain_name
}

Build the Next.js app

In the directory of your Next.js app run the bundler (don't worry if you have a custom next.config.js we got you covered):

npx tf-next build

Deploy the Next.js app

In the same directory now run the following commands:

# Make the AWS credentials available for Terraform
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>

# Initialize Terraform
terraform init
# Deploy your app
terraform apply

After Terraform successfully created the deployment, it you should show you the following output on your terminal:

> Apply complete!
>
> Outputs:
>
> cloudfront_domain_name = "xxx.cloudfront.net"

When you visit the https://xxx.cloudfront.net domain in your browser you should now be able to see your application deployed serverless on AWS!

Even if your app just don't need server-side rendering (SSR), our setup works for this too without any extra config.

We have made some example applications to try out on our GitHub repo to checkout:

Complete example (with SSR, static routes, rewrites and redirects)
Static example (no SSR, just static sites, still supports rewrites and redirects)
Custom domain (In case you just don't want to host your site on a xxx.cloudfront.net subdomain)

Thanks for reading this far, if you have questions or feature requests, you can reach out on Twitter or GitHub.

Have a great day!

How to unpack .wpress archive files created by the All-in-one-Wp-Migration Wordpress plugin

Felix Haus — Sat, 21 Nov 2020 20:35:47 +0000

Recently I needed to download some files from a Wordpress installation where the client only gave me access to the admin dashboard. Fortunately the All-in-One WP Migration plugin was already installed, so I could take a quick backup of the whole site by downloading the installed plugins, theme and database.

To my surprise downloading the backup from the All-in-One WP Migration plugin only gave me a single compressed migration.wpress file that any unpack tool refused to extract. A little web search brought me to a five year old tool called Wpress-Extractor but the provided binaries for MacOS refused to work because the package was already too old.

So I decided to rewrite this little helpful tool in Node.js to make it cross-platform compatible for Windows, MacOS and Linux.

Ok here it is: A simple 2-step tutorial how to extract a file with the .wpress extension on your computer:

1. Step

Make sure that you have Node.js installed in your computer:



node --version
# => v14.12.0

2. Step

In your terminal navigate to the location where the .wpress file is downloaded (e.g. ~/Downloads) and run the following command:



npx wpress-extract migration.wpress

It then creates a new folder migration/ where the content is extracted into.

That's it for today. If you would like to take a deeper look at this tool, the source code is open source, so feel free to visit the GitHub repository:

ofhouse / wpress-extract

A simple Node.js tool for extracting wpress archive files generated by the All-in-one-Wp-Migration Wordpress plugin.

Enhance your Stencil Web Components in Storybook with Knobs, Actions and JSX

Felix Haus — Wed, 04 Mar 2020 15:17:31 +0000

In the previous part of this series we got our setup of Stencil and Storybook up and running. This part goes a little deeper and we'll learn how to improve our stories by introducing Storybook's Knobs and Actions addons to our existing project.
Finally we'll learn how to simplify our stories by writing our Stencil Web Components directly in JSX rather than in plain JavaScript.

Note: If you are here to learn how to write your stories in JSX, you can skip to the end of this article: Use JSX to render your components in Storybook.

Adding Knobs and Action addons to the stack

To make a greater use of Storybook we first add the Knobs and Actions addons to our existing setup. The Knobs addon provides us a simple interface to modify the properties of our Web Components on the fly. The Actions addon logs all events from our Web Component, so that we can see which events are emitted.

First we install the addons:

npm i --save-dev @storybook/addon-knobs @storybook/addon-actions

And then add them to our storybook configuration:

// .storybook/main.js

...
module.exports = {
  stories: ['../src/**/*.stories.js'],
  addons: [
    '@storybook/addon-notes/register',
+   '@storybook/addon-knobs/register',
+   '@storybook/addon-actions/register',
  ],
  ...
}

Add a new component

To learn how to integrate the Storybook addons with a Web Component we start by creating a new button component called <my-button>. Again we use Stencil's built-in CLI here for creating a boilerplate for our new component:

npx @stencil/core generate

After the CLI has finished creating the new files for our component, make sure to run a quick build so that Stencil also adds a simple readme to this component:

npm run build

Since our new button component is pretty empty right now we give it more content by replacing it with the following content:

// my-button.tsx
import { Component, Prop, h, Event, EventEmitter } from '@stencil/core';

@Component({
  tag: 'my-button',
  styleUrl: 'my-button.css',
  shadow: true,
})
export class MyButton {
  @Event() onClick: EventEmitter;
  @Prop() label: string;

  handleClick(event: UIEvent) {
    this.onClick.emit(event);
  }

  render() {
    return <button onClick={this.handleClick.bind(this)}>{this.label}</button>;
  }
}

Our component now has a property label where we can define what text is shown on our button and an onClick event which is fired when the button is clicked.
Now we are ready to add a new story for this button by creating a new file called my-button.stories.js in the same directory:

src/
└── components/
    ├── my-component/
    └── my-button/
        ├── my-button.css
+       ├── my-button.stories.js
        ├── my-button.tsx
        └── readme.md
...

Inside of the file we now define our story:

// my-button.stories.js

import { storiesOf } from '@storybook/html';
import { withKnobs, text } from '@storybook/addon-knobs';
import { withActions } from '@storybook/addon-actions';

import readme from './readme.md';

storiesOf('My Button', module)
  .addDecorator(withActions('onClick'))
  .addDecorator(withKnobs)
  .add(
    'Default',
    () => {
      const buttonElement = document.createElement('my-button');
      // Knob property Label
      buttonElement.value = text('Click Me!', 'Label');
      // Event handler for onClick
      buttonElement.onClick = () => {
        console.log('Clicked');
      };

      return buttonElement;
    },
    {
      notes: {
        markdown: readme,
      },
    }
  );

When we now start storybook we can now see that a new panel with our addons is added to the view:

Use JSX to render your Web Components in Storybook

Maybe you are wondering why we wrote the implementation of our Stencil components in JSX while our stories use plain JavaScript to initialize our components. Let's change that.
I saw the following tweet by Surma last week where he shows that with a little help of a babel transformer and 15 lines of code it is pretty easy to write DOM in JSX:

Surma

@dassurma

Wait, is this news to anyone? Am I just late to the party? Am I missing something?

With this 15 line `h` function, you can use JSX for DOM ops w/ all the good stuff:

- Inline event handlers
- Custom elements
- Props and attributes (which React still can’t do, lol)

I dig it 🤨

18:59 PM - 26 Feb 2020

66 482

There is already a tiny library out there called jsx-dom so we don't have to copy the code from the screenshot.

In order to make it work, we need to add 3 new packages to our setup:

npm i --save-dev @babel/plugin-syntax-jsx @babel/plugin-transform-react-jsx jsx-dom

Then we add a .babelrc file to the root of our project:

// .babelrc

{
  "plugins": [
    "@babel/plugin-syntax-jsx",
    [
      "@babel/plugin-transform-react-jsx",
      {
        "pragma": "h"
      }
    ]
  ]
}

Now we are ready to rewrite the story for our button component in JSX. Simply make sure to add the pragma import { h } from 'jsx-dom'; to the top of every story that uses JSX. We then can bind the properties to variables or inline them directly:

// my-button.stories.js

import { storiesOf } from '@storybook/html';
import { withKnobs, text } from '@storybook/addon-knobs';
import { withActions } from '@storybook/addon-actions';
import { h } from 'jsx-dom';

import readme from './readme.md';

storiesOf('My Button', module)
  .addDecorator(withActions('onClick'))
  .addDecorator(withKnobs)
  .add(
    'Default',
    () => {
      const label = text('label', 'Label');

      return (
        <my-button
          label={label}
          onClick={() => {
            console.log('Clicked');
          }}
        ></my-button>
      );
    },
    {
      notes: {
        markdown: readme,
      },
    }
  );

Thanks for reading. There are still some features which are missing in this setup (e.g. Hot-Module-Replacement) which I hopefully can figure out in the coming weeks. So feel free to follow me here for more updates on this topic!

A live-demo of the Storybook is available here: https://ofhouse.github.io/storybook-stencil-example
If your are interested to try it out by yourself, you can check out the full repository on GitHub:

ofhouse / storybook-stencil-example

Example project which uses Stencil components in Storybook.

Storybook Stencil Example

This is a starter project for building a Web Component library with Stencil and Storybook.

Getting Started

To start clone this repo into a new directory and run the following commands:

npm install
npm start

For a step-by-step tutorial how to recreate this from scratch you can follow this series of blog posts:

Part 1: Build a Web Component library with Stencil and Storybook

Part 2: Enhance your Stencil Web Components in Storybook with Knobs, Actions and JSX

Features

Author

Felix Haus Website • Twitter

License

MIT - see LICENSE for details.

View on GitHub

Build a Web Component library with Stencil and Storybook

Felix Haus — Tue, 18 Feb 2020 16:48:41 +0000

In this little tutorial we learn how to add Web Components created with Stencil to a Storybook setup. Stencil is a framework which let us write Web Components in a JSX-style syntax similar to React's class-components. It then compiles it to native Web Components code to make it usable in the browser.

1. Create a new Stencil project

First we initialize a new Stencil project from scratch with Stencil's handy CLI tool. It generates an initial project structure for us where we can simply add new components later on.

Note: If you already have a Stencil project you can skip this step and go straight to Step 2.

npm init stencil

In the following dialog Stencil asks us to pick a project type. Since we want to generate a library of Web Components choose the component option here and continue.

In the last step of the project generator we choose a name for the project, for simplicity we name it storybook-stencil-example.

Now we navigate into our newly created stencil project and install the dependencies:

cd storybook-stencil-example  # Navigate into project dir
npm i                         # Install dependencies

2. Add Storybook to the project

Because Stencil components are compiled to Web Components we simply can use Storybook for HTML project type here:

# Bootstrap storybook
npx -p @storybook/cli sb init --type html

# Install additional dependencies for our setup
npm i --save-dev \
  write-file-webpack-plugin \
  copy-webpack-plugin \
  @storybook/addon-notes

Now we need to make some changes to the default configuration from Storybook. We

// .storybook/main.js
const fs = require('fs');
const path = require('path');
const CopyPlugin = require('copy-webpack-plugin');
const WriteFilePlugin = require('write-file-webpack-plugin');

const OUTPUT_DIR = '../dist';
// Stencil names the project entry the same as the project
// Look for the file `dist/<your-project-name>.js` to find out what to insert here
const PROJECT_NAME = 'storybook-stencil-example';

module.exports = {
  stories: ['../src/**/*.stories.js'],
  addons: ['@storybook/addon-notes/register'],
  // Custom webpack config to tell Storybook where to find the compiled files from Stencil
  async webpackFinal(config) {
    config.entry.push(path.join(__dirname, OUTPUT_DIR, `${PROJECT_NAME}.js`));
    fs.readdirSync(path.join(__dirname, OUTPUT_DIR, 'collection/components')).map(file => {
      jsFilePath = path.join(__dirname, OUTPUT_DIR, `collection/components/${file}/${file}.js`);
      try {
        if (fs.existsSync(jsFilePath)) {
          config.entry.push(jsFilePath);
        }
      } catch (err) {
        console.error(err);
      }

      // Add CSS
      let cssFilePath = path.join(
        __dirname,
        OUTPUT_DIR,
        `collection/components/${file}/${file}.css`
      );
      try {
        if (fs.existsSync(cssFilePath)) {
          config.entry.push(cssFilePath);
        }
      } catch (err) {
        console.error(err);
      }
    });

    // Add all static files to Storybook
    config.plugins.push(
      new CopyPlugin([
        {
          from: '**/*',
          to: './',
          context: 'dist',
        },
      ])
    );

    // Write the files to disk and not to memory
    config.plugins.push(new WriteFilePlugin());

    return config;
  },
};

3. Create our first story

The Stencil project setup has already added a sample component for us named my-component. So let's create our first story for this component. Inside the component folder add a new file my-component.stories.js:

src/
└── components/
    └── my-component/
        ├── my-component.css
        ├── my-component.e2e.ts
        ├── my-component.stories.js  # <-- Add the file here
        ├── my-component.tsx
        └── readme.md
...

Of course we could also write the stories in TypeScript because stencil already relies on it but to keep things simple we use plain JavaScript for now.

// my-component.stories.js
import readme from './readme.md';

export default {
  title: 'My Component',
  parameters: {
    markdown: readme,
  },
};

export const Default = () => `
  <my-component first="Millie" middle="Bobby" last="Brown"></my-component>
`;

Importing the auto-generated readme.md from Stencil gives us a free documentation of our component which can also be showed in Storybooks "Notes" tab of the component.

4. Development workflow

To make the best use of Stencil and Storybook, both support a live-reload development workflow so that we can see changes we make to our Stencil components directly in Storybook without reloading the browser.
To make this work we start the Stencil dev server and the Storybook dev server parallel in two different terminals:

# Terminal 1 - Run Stencil compiler in watch mode
npm start

# Terminal 2 - Run Storybook
npm run storybook

Now the final result should now look like this in the browser. The canvas gives us a preview of our component while the note tab holds the documentation of the component itself.

You can also see a live-demo of the Storybook here: https://ofhouse.github.io/storybook-stencil-example

This is only a basic setup guide for Stencil and Storybook, to make use of Storybook's advanced features like Knobs or Actions I will add a second tutorial shortly. So follow me for more content!

This guide was made possible by the work of of Bobby Johnson. He has made a really nice video of the whole process of his Stencil and Storybook setup here: Using StencilJS with Storybook on YouTube

You can find the whole example project from this tutorial in the following repository:

ofhouse / storybook-stencil-example

Example project which uses Stencil components in Storybook.

Storybook Stencil Example

This is a starter project for building a Web Component library with Stencil and Storybook.

Getting Started

To start clone this repo into a new directory and run the following commands:

npm install
npm start

For a step-by-step tutorial how to recreate this from scratch you can follow this series of blog posts:

Part 1: Build a Web Component library with Stencil and Storybook

Part 2: Enhance your Stencil Web Components in Storybook with Knobs, Actions and JSX

Features

Author

Felix Haus Website • Twitter

License

MIT - see LICENSE for details.

View on GitHub

Add a Bash-like autocomplete to your PowerShell

Felix Haus — Fri, 27 Dec 2019 18:54:10 +0000

I mostly use Ubuntu or MacOS for development, but recently I switched sides because I needed the power from my Windows gaming machine to start playing around with Blender and Unreal Engine.

What I missed much when using the PowerShell console was the autocomplete ability which Bash offers:

When you begin to type a command and hit Tab Bash shows you all available commands which begin with the phrase you typed and you can then select the one you want with the arrow keys.

PowerShell by default only completes the command immediately without showing you all available commands.
If you already started typing the beginning of a command you can use ↑ / ↓ to cycle through your history to autocomplete the command with the parameters you have used before.

Cycling through the history with the arrow keys is also supported by PowerShell but it completely ignores what you have already typed and replaces everything with the last used command from the history.

Enable better autocompletion in your PowerShell

Thankfully PowerShell already has this functionality built-in provided by a module called PSReadline.
You simply have to enable it in your PowerShell profile (The PowerShell equivalent to your .bashrc) 👏:

Open or create a new PowerShell Profile by typing the following commands directly in your PowerShell:

# Create profile when not exist
if (!(Test-Path -Path $PROFILE.CurrentUserAllHosts)) {
  New-Item -ItemType File -Path $PROFILE.CurrentUserAllHosts -Force
}

# Open the profile with an editor (e.g. good old Notepad)
ii $PROFILE.CurrentUserAllHosts

In the editor add the following lines to the profile:

# Shows navigable menu of all options when hitting Tab
Set-PSReadlineKeyHandler -Key Tab -Function MenuComplete

# Autocompletion for arrow keys
Set-PSReadlineKeyHandler -Key UpArrow -Function HistorySearchBackward
Set-PSReadlineKeyHandler -Key DownArrow -Function HistorySearchForward

Save the file and reopen your PowerShell, now you can use the advanced autocomplete features.

Credit for this goes to StackOverflow users svick and JerryGoyal which have posted this in their answers.

Bonus: Add the `open` command from MacOS to your PowerShell

On MacOS there is the powerful open command to open folders in Finder (the file explorer from MacOS) or files with their default application from the terminal.
PowerShell also has this command built-in which is called ii (Which stands for Invoke-Item).
Because I find the term ii hard to remember I added an open alias for it which makes it more convenient when switching between the platforms.

Adding a new alias to the PowerShell profile is really simple with the New-Alias command, so simply edit your profile and add the following line:

# New-Alias <alias> <aliased-command>
New-Alias open ii

Save it and reopen your PowerShell and test it by typing open . to open an Windows explorer window in your working directory.

Last tip: Use the new Windows Terminal

To make your PowerShell experience even better you should also install the new Windows Terminal preview from the Microsoft store:
https://www.microsoft.com/store/productId/9N0DX20HK701

It offers tabs and a better customization than the default console in Windows.

I am still pretty new to PowerShell so if you have other tips to increase the productivity like this I would love when you leave a comment here. 💖

AngularJS: Hot-Module-Replacement with babel-plugin

Felix Haus — Sun, 08 Dec 2019 17:25:44 +0000

Note:
In 2020 AngularJS will turn 10 years old and with it's final sunset is only 1.5 years away (on June 30, 2021) you should not start to write new applications using AngularJS!

Despite its age there are still some AngularJS applications out there.
While the most websites on the internet already have replaced AngularJS by something newer, there are still some pretty large AngularJS applications alive behind the safe firewalls of company-intranets.
So if you still have to deal with AngularJS there is some good news: While upgrading from AngularJS may not be an option for you, you can still give your development experience a decent upgrade by enabling hot-module-replacement on your project.

Upgrade your developer experience by using Hot-Module-Replacement

The only requirement for this is that your project is already uses a bundler (like webpack or Parcel) which supports hot-module-replacement (HMR) and babel to transform your source.

Next install the babel-plugin-ng-hot-reload package from npm:

npm i -D babel-plugin-ng-hot-reload     # npm or
yarn add -D babel-plugin-ng-hot-reload  # yarn

Now, update your .babelrc.js file and add the newly installed plugin:

// .babelrc.js
module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        modules: false, // <- The plugin works with es-modules!
      },
    ],
  ],
  plugins: [
    'babel-plugin-ng-hot-reload',
  ],
};

When you are using Parcel no other configuration is necessary.
If you're using webpack, make sure to enable hot-module-replacement in your webpack.config.js:

// webpack.config.js
const webpack = require('webpack');

module.exports = {
  mode: 'development,
  entry: [
    `${require.resolve('webpack-dev-server/client')}?/`, // <- add
    require.resolve('webpack/hot/only-dev-server'), // <- add
    './src/index.js'
  ],
  output: {
    path: 'dist',
    filename: 'app.js',
    publicPath: '/',
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: ['babel-loader'],
        exclude: /node_modules/,
      },
      ...
    ],
  },
  resolve: {
    extensions: ['.js'],
  },
  plugins: [
    ...
    new webpack.HotModuleReplacementPlugin(), // <- add
  ],
  devServer: {
    hot: true, // <- add
  },
};

Now you can edit your HTML, CSS or JavaScript files and they should be replaced without a reload of your application.

Fore some more advanced use-cases here are some examples available on CodeSandbox:

Webpack / JavaScript demo on CodeSandbox
- Uses angular as global variable
Webpack / TypeScript demo on CodeSandbox
- Uses TypeScript babel-preset
- Uses angularjs-annotate babel-plugin
- Uses Lazy-Loading provided by ocLazyLoad
Parcel / TypeScript demo on GitHub (Does not run on CodeSandbox)
- Uses Parcel instead of webpack

Some words about `babel-plugin-ng-hot-reload`

Under the hood the plugin relies on the solid work of the ng-hot-reload library by Oskari Noppa.
Since this library originally provides a webpack-loader the usage was limited to webpack.
Another limitation from the loader is that it is only compatible with commonJS modules created by babel, so if your are using import and export syntax it gets rewritten to require('...') and module.exports = {...} which is incompatible with tree-shaking.

This babel-plugin takes a deeper look at your code by preserving the imports and exports and only adds the code required for the hot-reload to the modules which are interacting with angular.
So the code for the browser is less bloated and can use the same tree-shaking like the production version (Lazy-loaded AngularJS modules are also supported by the plugin).

If you want to know more, the the plugin and the examples are open source and available here:

ofhouse / babel-plugin-ng-hot-reload

Hot reloading for AngularJS apps via babel plugin.

🔥 babel-plugin-ng-hot-reload

A babel plugin which enables hot module replacement in AngularJS applications.
The plugin is based on the ng-hot-reload webpack loader but is rewritten as babel plugin so that it is compatible with es-module syntax and every bundler which supports the hot-replacement API (e.g. webpack or parcel).

Getting started

To see it in action you can simply checkout the examples on CodeSandbox:

Webpack / JavaScript demo on CodeSandbox

Webpack / TypeScript demo on CodeSandbox

Parcel / TypeScript demo on CodeSandbox (There is an issue with HTML import, see: FAQ)

npm i -D babel-plugin-ng-hot-reload     # npm or
yarn add -D babel-plugin-ng-hot-reload  # yarn

Add the following to your babelrc.js file:

// without options
module.exports = {
  plugins: ['babel-plugin-ng-hot-reload'],
};
// with options
module.exports = {
  plugins: [
    [
      'babel-plugin-ng-hot-reload',
      {
        angularGlobal: false,
        forceRefresh: true

…

View on GitHub

DEV Community: Felix Haus

Create your own serverless image optimizer for Next.js in 5 minutes

Deploy the serverless image optimizer to AWS

milliHQ / terraform-aws-next-js-image-optimization

A drop-in image optimization loader for Next.js image component powered by AWS Lambda.

Terraform Next.js Image Optimization module for AWS

Features

Architecture

Usage

1. Deploy the module to AWS

Looking for a full stack solution to deploy Next.js on AWS?

Why we self-host our serverless Next.js site on AWS with Terraform

Becoming independent

Understanding the Next.js routing

Preparing Next.js for a serverless environment

Deploy Next.js to AWS

milliHQ / terraform-aws-next-js

Terraform module for building and deploying Next.js apps to AWS. Supports SSR (Lambda), Static (S3) and API (Lambda) pages.

Terraform Next.js module for AWS

Features

Architecture

Prerequisites

Build the Next.js app

Deploy the Next.js app

How to unpack .wpress archive files created by the All-in-one-Wp-Migration Wordpress plugin

1. Step

2. Step

ofhouse / wpress-extract

A simple Node.js tool for extracting wpress archive files generated by the All-in-one-Wp-Migration Wordpress plugin.

Enhance your Stencil Web Components in Storybook with Knobs, Actions and JSX

Adding Knobs and Action addons to the stack

Add a new component

Use JSX to render your Web Components in Storybook

ofhouse / storybook-stencil-example

Example project which uses Stencil components in Storybook.

Storybook Stencil Example

Getting Started

Features

Author

License

Build a Web Component library with Stencil and Storybook

1. Create a new Stencil project

2. Add Storybook to the project

3. Create our first story

4. Development workflow

ofhouse / storybook-stencil-example

Example project which uses Stencil components in Storybook.

Storybook Stencil Example

Getting Started

Features

Author

License

Add a Bash-like autocomplete to your PowerShell

Enable better autocompletion in your PowerShell

Bonus: Add the open command from MacOS to your PowerShell

Last tip: Use the new Windows Terminal

AngularJS: Hot-Module-Replacement with babel-plugin

Upgrade your developer experience by using Hot-Module-Replacement

Some words about babel-plugin-ng-hot-reload

ofhouse / babel-plugin-ng-hot-reload

Hot reloading for AngularJS apps via babel plugin.

🔥 babel-plugin-ng-hot-reload

Getting started

Bonus: Add the `open` command from MacOS to your PowerShell

Some words about `babel-plugin-ng-hot-reload`