Forem: nuro

Cloudflare is almost perfect

nuro — Thu, 16 Jan 2025 22:41:34 +0000

If you're building a platform or product nowadays, as a developer in some way or another Cloudflare may fit into your stack. Whether that be from just using their network for DDoS protection, using R2 for cheaper object storage, or even going all in on using their Workers product for serverless compute.

However, having poked around with Cloudflare for a while now, there are a few things that I think are missing from their platform that would make it a perfect platform for developers.

So, since we're close to the end of the year I thought I may as well make a little wish list of things I'd like to see from Cloudflare in 2025.

Containers

Starting off with my biggest ask: Containers, containers and more containers!

I used to be a big fan of serverless computing or lambdas, and I still think they have their place. But I have seen too many horror stories of insane bills & issues myself of having to work around their limitations that if I was to build a product today I would not even bother with serverless lambdas at all and instead containerize everything.

With a container pretty much all the common problems go out the window, especially those stupid cold start issues.

The problem right now though is most other container-as-a-service products are either too expensive or too limited in functionality. Google Cloud Run is the closest to what I would want, but it is both too expensive to run and also locks you into the Google Cloud ecosystem which is both complex and expensive in every other way.

Now, Cloudflare did already announce earlier this year that they are already working on their own container-as-a-service product, and is apparently already in use in a number of other Cloudflare products. So I am really looking forward to seeing this product come out of closed alpha/beta and into general availability for everyone to use.

But with that said, I want to emphasize a few key features I really hope Cloudflare considers:

Global deployments: Workers are already deployed globally to multiple regions, let containers do the same. Let me just check a box to add a region & leave Cloudflare to handle the networking and geo-routing.
Minimum scale count: 🖕 cold starts. Let me just set a minimum container / pod count so I can have at least 1 container always running.
Sidecar containers: Google Cloud Run has a cool feature where you can run multiple containers next to each other. So for example, if you want to run Caddy or Traefik as a reverse proxy for your ingress container and then have both your web frontend container & backend api container co-located in the same service, you can do that & have everything be super low latency.
Image registry: Offer a 1st party image registry & make it easy to use. If not, make supporting the GitHub Container Registry the go-to. For me I don't want to bother with Docker Hub when GitHub Container Registry does everything I need.
S3 volume mounts: Another cool feature Google Cloud Run offers is you can access a Google Cloud Storage (S3) bucket via file-system rather than over the network.

Workers HTTP imports

A while ago I made this post on Bluesky about how if you want to quickly deploy a web application, whether that be a RESTful API or a server-side rendered application, Deno Deploy with Hono is an absolutely killer combination. Especially since you can do it all via a web based editor.

Being able to do something similar to this with Cloudflare Workers would be amazing. However right now there is one big blocker, besides TypeScript support, and that is that there is no native support for HTTP imports.

Imagine to create a super basic RESTful API all you needed to do was go to the Cloudflare dashboard, go to the workers page, click "Create" & then paste in the following code:

// _worker.js
import { Hono } from 'https://esm.sh/hono@4.6.11';

const app = new Hono();
app.get('/', (c) => c.text('Hello World!'));

export default {
    fetch: (request, env, ctx) => app.fetch(request, env, ctx),
};

No more need to set up a new Node.js project, repository to store it all, connect the repo to a CI/CD pipeline, etc. Just write the code and deploy it using your favourite packages via HTTP imports.

R2 feature compatibility

R2 is amazing! Plain and simple object storage. You just give it data to store and that's it.

But that being said, there is a few small missing features that I really hope get added:

Encryption: For the rare use case it would be handy to be able to securely store data at rest, kind of like how Google Cloud Storage does it.
Revision history: Being able to see the history of a file and restore it to a previous version. This would be super helpful for infrastructure as code files like Terraform state files.
S3 client: @aws-sdk/client-s3 sucks, both in terms of DX & package size. I wish Cloudflare would make their R2 worker API a general purpose package for anyone to use. The closest I have found that is good in the meantime is @bradenmacdonald/s3-lite-client.

The dashboard sucks

I'm sorry but I will put it blunt, it does suck.

It's slow, confusing UX where products are placed sparatically, fast page loads but data loads in slowly filling the page with loading spinners & often giant red banners at the bottom telling me about some internal error when trying to load the page.

This isn't as much of an issue if you're using any kind of infrastructure-as-a-code system, but even then you would still need to use the dashboard to view analytics, billing, etc, and on that scenario it would be helpful if the dashboard was a bit more user friendly.

Support more TLD's

Over the past year or so I have slowly been migrating all my domains to Cloudflare but a lot of which I have had to wait for a little bit for some missing top-level domains to be added to Cloudflare's registrar.

Pretty much all of the essential TLD's have been added now, but I do hope Cloudflare continues to add more, like .rs for Rust projects`, so that in future I don't even need to consider NameCheap or some other 3rd party TLD provider and instead I can just buy and consolidate everything in one place. Not exactly a sore spot but a nice-to-have.

Sharable API key permissions

This is a small one, but I think it would be really helpful for a niche number of developers and blog writers.

In short, I wish that when you were creating a new API token in the Cloudflare dashboard that it would give you the option to copy a code, likely a hash of some kind, that you could then share around to paste in the exact permissions needed for something.

For example: Say you're writing a blog post on how to use deploy a Cloudflare Pages site using Terraform. Terraform needs a Cloudflare API token to do this, but you don't want to give it full access to your account. So you create a new API token with the exact permissions needed, copy the hash, and then paste it into your blog post.

Very niche but handy if there is a lot of permissions that need to be added or say permissions get changed or removed, the hash could automatically handle populating the replacement.

Analytics site permissions role

Lastly this sort of follows on from the above, but currently from my testing there is no way to create an API token that has write access for Cloudflare analytics sites so there is no way to automate the creation of new analytics sites with something like Terraform. Or if there is a permission that can do it, clearly document it instead. Currently there is a "Account Analytics" or "Analytics" permission but both seem to be read only.

And that's it, for now anyway. I am sure over the course of the next year or so I will think of or find many other little features or fixes that Cloudflare needs to implement to finally make their platform over that line where I would use Cloudflare's suite of products for everything I need to build a product.

How to build an Astro collection loader

nuro — Thu, 16 Jan 2025 22:39:43 +0000

A few days ago Astro released version 1.14 which introduced a new feature called the "Content Layer API". This feature builds on the existing content collections feature and instead expands it so you can use data from sources other than local files within the Astro project repository.

Now, to get started the Astro team has already published a number of loaders to deal with the most common possible cases you may need. Including "feeds" like RSS feeds, CSV files, etc. But what if you wanted to build your own? Well it's actually quite simple.

Setting up Astro

First things first, you need to set up a new Astro project. You can do this by running the following command:

npm create astro@latest

This will walk you through a very fancy CLI guide to set up your project.

Once you have done that, you can run the following command to start your project:

npm run dev

With this up and running you can visit http://localhost:4321 to see your new Astro project.

Enable the experiment

Next, you will need to make one slight tweak to the Astro configuration file to enable the Content Layer API as it's currently still experimental.

To do this, open the astro.config.mjs file and add a experimental object with a contentLayer key set to true like so:

// astro.config.mjs 
import { defineConfig } from 'astro/config';

// https://astro.build/config
export default defineConfig({
    experimental: {
        contentLayer: true,
    },
});

The basic structure

With the experimental API enabled we can now actually start to build out the basic structure for a collection loader.

Now, for the sake of example I'll be using TypeScript but it's not strictly required.

First up, create a new file in your project. I'll call mine src/loaders/jokes.ts. This file will be responsible for loading in a collection of posts.

// src/loaders/jokes.ts
import type { Loader } from 'astro/loaders';

export const jokesLoader: Loader = {
    name: 'jokes',
    load: async (context) => {},
};

At its most basic premise a loader is an object with a 2 required properties & one optional property:

name (Required): This will be the name of the loader and how it will show up in logs and such.
load (Required): Here is the actual "loader logic" function where you actually fetch the data from whatever source you need. This function exposes a loader context parameter which can be used to access things like the store where the data will actually get stored, logger for logging, etc.
schema (Optional): If you want to provide a Zod schema to validate the data after it's been fetched you can do so here.

Fetch some data

Now we need some data, let's use this dad joke API to get a bunch of random dad jokes.

To do this in the load function all we need to do is make a fetch request. For this API we just need to make sure we set the Accept header to application/json to get the data in JSON format.

// src/loaders/jokes.ts
import type { Loader } from 'astro/loaders';

export const jokesLoader: Loader = {
    name: 'jokes',
    load: async (context) => {
        const response = await fetch('https://icanhazdadjoke.com/', {
            headers: {
                Accept: 'application/json',
            },
        });

        const json = await response.json();

        context.logger.info(JSON.stringify(json));
    },
};

I've added a console.log statement for now just so we can check it works. But how do we do that?

Using the loader

With some actual logic in the loader we can hook it up to a collection to see what data we get back from the API.

To do this create the following file src/content/config.ts:

// src/content/config.ts
import { defineCollection } from 'astro:content';

import { jokesLoader } from '../loaders/jokes';

const jokes = defineCollection({
    loader: jokesLoader,
});

export const collections = {
    jokes,
};

With this we should now have a new collection called jokes that we can access in our Astro project.

If we run a build of the project with npm run build we should see the loader being run and the data being logged to the console.

21:32:37 [content] Syncing content
21:32:37 [jokes] {"id":"mWS7hVKRSnb","joke":"Past, present, and future walked into a bar.... It was tense.","status":200}
21:32:37 [content] Synced content

Perfect, we can see our loader ran by the [jokes] log message and the data being returned from the API. Additionally it confirms the data structure we get back.

Store the data

Now we have some data we need to actually store it so we can access it in our Astro project.

To do this we can use the store scoped data store that is available on the context parameter. This ScopedDataStore appears to be some form of a superset of a regular Map object.

When actually setting the data you need to provide a unique id for the data, along with the data itself. This works quite well for us here as the API gives us an id field for each joke.

// src/loaders/jokes.ts
import type { Loader } from 'astro/loaders';

export const jokesLoader: Loader = {
    name: 'jokes',
    load: async (context) => {
        const response = await fetch('https://icanhazdadjoke.com/', {
            headers: {
                Accept: 'application/json',
            },
        });

        const json = await response.json();

        context.store.set({
            id: json.id,
            data: json,
        });
    },
};

Accessing the data

Since we removed the logging builds will still succeed if you run npm run build but we won't see the data being logged anymore.

To actually access the data, you can access it like you would any other collection in Astro.

For example, in an Astro file you can use the getCollection function to get the data.

<!-- src/pages/index.astro -->
---
import { getCollection } from 'astro:content';

const jokes = await getCollection('jokes');
console.log('jokes', jokes);
---

Running npm run build with the above added you should see something along the lines of:

 generating static routes
22:05:09 ▶ src/pages/index.astro
22:05:09   └─ /index.htmljokes [
  {
    id: '9prWnjyImyd',
    data: {
      id: '9prWnjyImyd',
      joke: 'Why do bears have hairy coats? Fur protection.',
      status: 200
    },
    collection: 'jokes'
  }
]
 (+6ms)
22:05:09 ✓ Completed in 9ms.

And just like that it works! Now every time you build your Astro project it will fetch a new dad joke from the API and store it in the collection.

Conclusion

And that's it! You've now built your own collection loader for Astro. This is a very basic example but it should give you a good starting point to build more complex loaders.

Later down the line this can be easily adapted into a function to return a loader so you could say take in some user options and publish it as a package for others to use.

I'm excited to see what other loaders people come up with now and in the future.

How to use Astro with Hono

nuro — Thu, 16 Jan 2025 22:35:54 +0000

Astro is the future of web frameworks. At least for me it is. It's been so nice to use & feels like the do it all framework to the point I want to use it for everything and anything.

However, that being said, for building APIs I am yet to find something as nice to use as Hono. It's simple, runs anywhere & has a very basic but usable RPC system similar to tRPC, but with less slow types.

So, with that, why not learn how to combine the 2 so you can have the best of both worlds?

Setting up Astro

First things first, you need to set up a new Astro project. You can do this by running the following command:

npm create astro@latest

This will walk you through a very fancy CLI guide to set up your project.

Once you have done that, you can run the following command to start your project:

npm run dev

With this up and running you can visit http://localhost:4321 to see your new Astro project.

Setting up Hono

Next, you will of course need to set up a basic Hono app.

To get started you will need to install Hono as a dependency. This can be done with the following command:

npm install hono

With Hono installed you'll need to create a new endpoint in Astro to point all requests to a Hono instance.

To do this create a new catch-all route in your src/pages/ directory. Something like: src/pages/api/[...path].ts.

With this file you can create a new basic Hono instance like so:

// src/pages/api/[...path].ts
import { Hono } from 'hono';

const app = new Hono().basePath('/api/');

Make note of the .basePath(...) part here, it's important. This tells Hono that all incoming requests should be prefixed with this path. In our case since we're using Astro, this will need to match the file structure of your Astro project. For example if your endpoint is in src/pages/foo/bar/[...path].ts then you should use /foo/bar/ as the base path.

Now, last up to finish setting up Hono we'll add a basic endpoint to retrieve some mock data.

// src/pages/api/[...path].ts
import { Hono } from 'hono';

const app = new Hono()
    .basePath('/api/')
    .get('/posts', async (c) => {
        return {
            posts: [
                { id: 1, title: 'Hello World' },
                { id: 2, title: 'Goodbye World' },
            ],
        };
    });

Binding Hono to Astro

With a basic Hono instance set up, we can now bind this to Astro.

Astro normally expects a function to be exported with the name matching the HTTP method it is expected to handle. Such as GET will handle GET requests, POST will handle POST requests etc.

Now, in our case we need to redirect all requests to Hono. This can be done by creating a new ALL export. So let's create a basic one of these that just returns some text for now:

// src/pages/api/[...path].ts
import { Hono } from 'hono';

import type { APIRoute } from 'astro';

// ...

export const ALL: APIRoute = () => new Response('Hello World');

Next up we can then access the context function parameter to access the incoming request & pass it to Hono's fetch method.

// src/pages/api/[...path].ts
import { Hono } from 'hono';

import type { APIRoute } from 'astro';

// ...

export const ALL: APIRoute = (context) => app.fetch(context.request);

And just like that you can now visit http://localhost:4321/api/posts to see your mock data being returned from Hono.

Add a typed RPC client

Now, for the final part of getting this whole thing working seemlessly. We can make it so when we want to make requests to this API you get typed request options like query parameters, headers etc, along with a fully typed response.

You can read more about how this all works in the Hono documentation.

To set this up is faily easy as all you will need to do export the type of your Hono instance & pass it to the special fetch client that Hono offers called hc.

First up, export the type of your Hono instance:

// src/pages/api/[...path].ts
import { Hono } from 'hono';

import type { APIRoute } from 'astro';

// ...

export type App = typeof app;

Now, to actually use this type we can create a basic Astro page with a client-side script to make a fetch request using the Hono client:

<!-- src/pages/index.astro -->
<script>
import { hc } from 'hono/client';

import type { App } from './api/[...path].ts';

const client = hc<App>(window.location.href);

const response = await client.posts.$get();
const json = await response.json();

console.log(json);
// { posts: [...] }
</script>

Conclusion

And you're done! You now have a basic Astro project set up using Hono as your API. With the added bonus of being able to make typed requests & get fully-typed responses.

I encourage more people to experiment & try out Hono with more projects because it is a truly amazing HTTP framework that can do so much more than many people realise. So much so that I am using it for all of my backend related projects & plan on creating some more posts on using it in future.

For now though, keep building & have fun!

Using GitHub as a CMS

nuro — Wed, 19 Jan 2022 12:35:13 +0000

Since re-launching my website with an all new redesign I added a number of cool features. One such feature I thought worth sharing about was my portfolio page as it actually uses GitHub as a CMS (Content Management System).

So, let's go through and breakdown why I added this feature, why not use some other service & of course how it works.

❓ Why

When re-designing my website I set out with a number of goals. One such goal was to retain a similar portfolio page to my existing website at the time which fetched all my GitHub repositories & just listed them all.

However, I wanted to improve on this page by adding some sort of curation to it. Preferably via some method that is quick, easy to use, can be accessed from almost anywhere & preferably free.

☁️ Headless CMS

I knew I needed some kind of headless CMS in some form to let me curate the content I wanted displayed, so I did some thinking & some research.

I found most people were happy to recommend other headless CMS services like Strapi, Sanity, GraphCMS, etc which did seem to do the job I wanted of providing a platform for me to curate & manage my content without having to redeploy. But most of them had the same issues that I didn't like.

Resilience

Is it overkill to try & have your personal portfolio website to have a 99.999% uptime? Probably.

Does it matter if my website goes down? No. But I like to try & treat as any other production environment & where possible not add another possible point of failure. In this case being a 3rd party service to serve the data for my portfolio page.

If the 3rd party service goes down will my content somehow still be magically served by some cache somewhere until the service comes back online? Or is there just going to be no content served at all?

"But you're fetching from GitHub, right? So you're still reliant on data from them" Fair point, yes I am. However, I am both more likely to trust GitHub's uptime & platform resilience than a CMS service, and it's easier to add in a fail safe so if GitHub does go down we can still serve content without them (More on this later).

Price

Some may call me cheap for this but another goal for my personal website is to be as cheap as possible. As of writing my website costs me $20/year to run. That's it.

How? Simple. $20/year for a domain, code hosted GitHub & deployed to Vercel. It's that cheap & I want to keep it that way.

So, the idea of paying for another service, however nice a lot of them look, is just not for me. So I wanted to find an alternative that would serve the same function I need it to but for zero additional cost.

🔨 How

If you'd rather just look at the final code to see how it works, go check the projects.ts file in my websites GitHub repository.

The short version of how it works is this: Using topics on GitHub you can filter what content you do & don't want to show. In my case I have given all my chosen repositories a portfolio topic & that will make the repository show up on my portfolio page.

To get this working there are 2 key things we're going to need: Next.js & the GitHub api. Optionally you can also use some kind of cache, like Upstash, to cache your data & save on requests to the GitHub api.

Fetching repositories

Starting off we will set up a base getServerSideProps function that will allow us to fetch the repository data on the server & pass the data to the client.

// portfolio.jsx
export async function getServerSideProps () {
    const response = await fetch('https://api.github.com/users/GITHUB_USERNAME/repos');
    const json = await response.json();
    return {
        props: {},
    };
};

Repository filtering

Here is where we can add our own custom logic to curate the data based on the data returned from GitHub. In this example we'll be filtering out all the repositories that both don't have the portfolio topic & are not archived.

// portfolio.jsx
export async function getServerSideProps () {
    // ...
    const repositories = json.map((repo) => {
        if (!repo.topics.includes('portfolio')) return null;
        if (repo.archived) return null;
        return repo;
    })
    .filter((project) => project !== null);
    return {
        props: {
            repositories,
        }
    }
};

GitHub Authentication

Next up is an optional step that I highly recommend to reduce the chance of hitting the GitHub api rate limit.

To complete this step you will first need to create a GitHub personal access token. You can follow the official guide here.

With your newly generated access token, add it to your .env file.

GITHUB_PAT=abc123

With it added you can update your fetch request to add the token to your request headers.

// portfolio.jsx
export async function getServerSideProps () {
    const response = await fetch('https://api.github.com/users/GITHUB_USERNAME/repos', {
        headers: {
            authorization: `token ${process.env.GITHUB_PAT}`,
        },
    });
    // ...
};

Caching

This last step is also optional but can help with platform resilience & response times. In short we'll use some form of super fast caching database, like Redis, to store the request data after the first request & from then on after serve the cached data instead of having to make multiple requests.

For my website I ended up using Upstash which offers a single single Redis database for free. I recommend following their guide to get started setting up your first Redis database.

With your database set up you should now have a REDIS_URL to add your .env file. It should look something like this rediss://USERNAME:PASSWORD@HOST:PORT. Don't worry if there isn't a username.

GITHUB_PAT=abc123
REDIS_URL=rediss://USERNAME:PASSWORD@HOST:PORT

Now that we have a database to access we need a client to access it with. There's a number of Redis client's, including Upstash's own client, but I personally prefer ioredis so that's what I will be using for this example but any others should work fine. Install it as a development dependency.

npm install --save-dev ioredis

Or using Yarn

yarn add -D ioredis

With it now installed we can create a new client instance to connect to our database.

// portfolio.jsx
export async function getServerSideProps () {
    const redis = new Redis(process.env.REDIS_URL);
    // ...
};

Finally we can add the actual logic to check whether the cache already has the data we need & if not we can fetch the data fresh from GitHub & store it in the cache before we finally return it.

// portfolio.jsx
export async function getServerSideProps () {
    // ...
    const cache = await redis.get('repositories');
    if (cache !== null)
        return {
            props: {
                repositories: cache,
            }
        }
    const repositories = ...
    redis.set('repositories', JSON.stringify(repositories));
    return {
        props: {
            repositories,
        }
    }
};

✅ Conclusion

And that's it, with all of that we have a very simple but resilient system that allows us to use GitHub to manage what content is displayed on our site, but also is not entirely reliant on GitHub so if there is any downtime for whatever reason on GitHub's end we still have the data cached.

// portfolio.jsx
export async function getServerSideProps () {
    const redis = new Redis(process.env.REDIS_URL);
    const cache = await redis.get('repositories');
    if (cache !== null)
        return {
            props: {
                repositories: cache,
            }
        }
    const response = await fetch('https://api.github.com/users/GITHUB_USERNAME/repos', {
        headers: {
            authorization: `token ${process.env.GITHUB_PAT}`,
        },
    });
    const json = await response.json();
    const repositories = json.map((repo) => {
        if (!repo.topics.includes('portfolio')) return null;
        if (repo.archived) return null;
        return repo;
    })
    .filter((project) => project !== null);
    redis.set('repositories', JSON.stringify(repositories));
    return {
        props: {
            repositories,
        }
    }
};
export default function Page({ repositories }) {
    return (
        <pre>
            {JSON.stringify(repositories, null, 4)}
        </pre>
    );
}

Improving the Next.js config

nuro — Thu, 23 Dec 2021 00:35:15 +0000

For the past few years I have been an avid lover of Vue.js and in the past year or so been using it in combination with Vite, an all new build tool that is just out of this world fast ⚡.
However, spending more time working in the industry I have learned to fall back in love with React and more specifically Next.js.

However, since switching back to using Next.js after so many years, I have noticed a number of things that have made me want to go back to using Vue + Vite.

As the title implies, this post is going to focus specifically on how to improve the Next.js config by focusing on a handful of the top/best config options used in other build tools like Vite.

🔧 More Options

In general I feel like there should be more options added to the config file. Looking at the shared options in Vite, here are just a few that would make a lot of sense to add:

build: Customize the build output

Offer more customization for the build configuration of your project. In the case of Next.js I feel a lot of existing build options could be moved here. EG: swcMinify, webpack, etc.
define: Define global constant replacements

As a good alternative to having to add NEXT_PUBLIC_ environment variables all the time you can use this to define public constant variables.
logLevel: Adjust console output verbosity
plugins: Array of plugins to use

Plugins are a big feature that I'm going to dive into more later.
root: Project root directory

Re-learning Next.js over the past few months I have been researching a number of open source projects, many of which like to point to a custom root directory. Most commonly a src/ directory.
server: Server options

Customize the server configuration with options like cors, port, etc.

The majority of these options simply add project structure flexability & extensibility for more advanced users.

❗ TypeScript

Moving onto what is, to me at least, one of the most obvious features. TypeScript support.

I personally don't like using the CommonJS syntax where possible. To the point that for most projects now when I want to write a simple Node script I quickly add tsup so I can use TypeScript & a number of other handy features.
One scenario I particularly hate is when a library offers a object type definition & but you have to use the JSDoc @type {import('...').TypeName} syntax to use it.

For comparison: This, to me, is ugly:

// next.config.js

/**
 * @type {import('next').NextConfig}
 */
module.exports = {
    // ...
}

This however, looks much cleaner:

// next.config.ts
import type { NextConfig } from "next";

export default {
    // ...
} as NextConfig;

No, type safety isn't needed for a config file. But when writing it it can be very helpful to have tools, such as intellisense, to help prompt any issues with your setup or help save you from having to even look up the conig documentation.

next.config.ts has been talked about for 3 years now & has still not been added. This issue has been tracking this request since first posted in 2018 and still to this day has people asking for it.

I can very much understand if there are more pressing features, bugs, etc that need to be addressed. But Next.js 12 has just been released, the Next.js core has been running on TypeScript since 2019 & Vercel has constantly preached how amazing TypeScript is to the point it works out of the box pretty much.
And yet, the Next.js config still only allows a CommonJS JavaScript file.

🔌 Plugins

One of the second features that I think would have the biggest & best impact on Next.js would be an all new plugins system.

Currently Next.js does provide a plugin system of sorts but is, as far as I can tell, community made & managed by nesting functions that return an updated Next.js configuration object. Not so pretty.

In an indeal world an all new plugins system could make it even easier to bootstap & customize a Next.js project with your favourite tools in a matter of minutes, not hours like it does today.

Imagine if you could add TailwindCSS to your Next.js project by just doing this:

npm install --save-dev next-plugin-tailwindcss
# Or with Yarn
yarn add -D next-plugin-tailwindcss

// next.config.js

/**
 * @type {import('next').NextConfig}
 */
module.exports = {
    plugins: [
        require("next-plugin-tailwindcss")(),
    ]
}

That's basically how Vite's plugin system works & how nice & easy it is to work with. It has a plugins property that allows you to simply provide an array of plugin methods that you call with your desired options.

This system has become so popular that there are a huge number of plugins to let you to almost anything and everything you could need. Here is a few examples of my favourites:

vite-plugin-icons: Access thousands of icons via Iconify.
vite-plugin-markdown: Import markdown files content, frontmatter, etc.
vite-plugin-pwa: Generate all assets needed to make your app PWA ready.
vite-plugin-windicss: Quickly add WindiCSS (TailwindCSS + some cool extras).

😎 Merged

With all of those features all put together you end up with something that looks a little like this:

// next.config.ts
import TailwindCSS from 'next-plugin-windicss';

import type { NextConfig } from "next";

export default {
    build: {
        swc: {
            minify: true,
        },
        webpack: (config, { dev, isServer }) => {
            // ...
        },
    },
    experimental: {
        // ...
    },
    images: {
        // ...
    },
    plugins: [
        TailwindCSS(),
    ],
    root: "./src/",
    server: {
        headers: [
            // ...
        ],
        port: 4000,
    },
} as NextConfig;

😇 Simplicity

One argunment I could see for NOT to make all these big, possibly breaking, changes to the config system would be "But Next.js is so simple to use. This will just add complexity".

Fair point. But if done correctly it could be backwards compatible with the current config system & then allows more experienced developers who do want to utilize some of the new features, such as plugins, TypeScript support, etc, can do so.

🤔 Conclusion

Of course all of this is just my opinion on how to improve the Next.js config system & how I think it should look, but others may have differing opinions / preferences, which I am very open to discussing.

For now though I feel like this needs to be something that should be discussed more in the community & looked into further as it could very much make Next.js even more powerful than it already is.

Hi, I'm Meadowcottage 👋🏻

nuro — Wed, 19 Jul 2017 02:53:26 +0000