From a41e2306bc4a599fc033a4be2c81352facbbd67a Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Fri, 9 Dec 2022 21:04:20 +0100 Subject: [PATCH 1/6] readme update --- README.md | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 8f927bf..4c5dada 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,31 @@ -# WayFinder -> Apply multiple nextjs middlewares with ease +

+
+ + + + + + + + + +

-> **WARN** -> Not yet published! +# Introduction +`next-wayfinder` is a lightweight (8kb minzipped) and flexible package that makes it easy to apply different Next.js +middlewares based on the route, without having to use cumbersome and error-prone path checks. +This allows you to easily manage and maintain your middlewares, and keep your app clean and organized. +## Installation ```sh - pnpm add next-wayfinder + npm install next-wayfinder ``` -## Usage +## Example +You can find several examples in the `examples` folder. + +Below is a basic implementation: ```ts // middleware.ts From 924acd8877173e7d8b156b771a17bc8480bc00f3 Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Fri, 9 Dec 2022 21:06:02 +0100 Subject: [PATCH 2/6] chore: changed `setupTests.js` to ts --- config/vitest.config.ts | 2 +- setupTests.js => setupTests.ts | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename setupTests.js => setupTests.ts (100%) diff --git a/config/vitest.config.ts b/config/vitest.config.ts index 5824b6c..865af7d 100644 --- a/config/vitest.config.ts +++ b/config/vitest.config.ts @@ -3,7 +3,7 @@ import { defineConfig } from "vitest/config"; export default defineConfig({ test: { globals: true, - setupFiles: 'setupTests.js', + setupFiles: 'setupTests.ts', coverage: { clean: true, reporter: ["text", "html"], diff --git a/setupTests.js b/setupTests.ts similarity index 100% rename from setupTests.js rename to setupTests.ts From e33f625c87677e426865a066255c203205b4f71b Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Sun, 11 Dec 2022 04:13:41 +0100 Subject: [PATCH 3/6] docs --- README.md | 63 ++++++++++++++++++++++++++++++++++++++----- config/tsup.config.ts | 5 ++-- 2 files changed, 60 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 4c5dada..2d24163 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@

# Introduction -`next-wayfinder` is a lightweight (8kb minzipped) and flexible package that makes it easy to apply different Next.js +`next-wayfinder` is a lightweight (_~3kb minzipped_) and flexible package that makes it easy to apply different Next.js middlewares based on the route, without having to use cumbersome and error-prone path checks. This allows you to easily manage and maintain your middlewares, and keep your app clean and organized. @@ -21,24 +21,44 @@ This allows you to easily manage and maintain your middlewares, and keep your ap npm install next-wayfinder ``` +## Why +This package was created based on [this discussion][discussion-link]. +In the discussion, a user highlighted the difficulty to handle complex routing inside the +Next.js middleware. For instance having a `withAuth` middleware only for paths matching `/dashboard/:path*` and an i18n middleware on a subdomain. +As of now, this can be archived via ugly path checking inside a middleware matching almost all the routes. +With `next-wayfinder` I aim to add some ease until Next will support officially multiple middleware for different matchers. -## Example -You can find several examples in the `examples` folder. -Below is a basic implementation: +## Quick Start +`next-wayfinder` exports an `handlePaths` function that can be used as middleware entry point. +It accepts an array of [`Middleware`](./src/types.ts) matching the route or the domain. + ```ts // middleware.ts import { handlePaths } from 'next-wayfinder' import { NextResponse } from 'next/server' +// the first matching middleware will be applied export default handlePaths([ { - matcher: '/dashboard/:lang/:path*', + matcher: '/dashboard/:path*', + // additional filter guard: params => params.lang === 'en', handler: async req => { - console.log(req.params) // <= params are injected by `handlePaths` + // url params are injected by `handlePaths` + // in addition to req.query + // this is done because you might want to handle paths + // that are not available under your `app` or `pages` directory. + console.log(req.params) + + + // do some checks + if ( !isAuthenticated(req) ) { + return NextResponse.redirect('/') + } + // continue the request return NextResponse.next() } }, { @@ -48,3 +68,34 @@ export default handlePaths([ } ]) ``` + +### What if I want to check paths on subdomain? +In some cases you might want to check paths on a subdomain (ie using the same project for handling both public website and the dashboard). +This can be easily archived by passing as handler an array of middleware. This `handlePaths` iterates recursively all the items provided (even the nested ones) +so a very high level of complexity can be "handled". Anyway to improve performance I'd recommend to keep it as simple as possible. + +```ts +// middleware.ts + +export default handlePaths([{ + domain: /^app\./, + handler: [ + { + matcher: '/', + handler: req => NextResponse.redirect(new URL('/dashboard', req.url)) + }, + { + matcher: '/:path*', + handler: () => NextResponse.next(), + } + ] +}]) +``` + +## Authors +This library is created by Federico Vitale - (https://github.com/rawnly) + +## License +The MIT License. + +[discussion-link]: https://github.com/vercel/next.js/discussions/43816#discussioncomment-4348363 diff --git a/config/tsup.config.ts b/config/tsup.config.ts index b819168..a2f582a 100644 --- a/config/tsup.config.ts +++ b/config/tsup.config.ts @@ -1,13 +1,14 @@ -import pkg from "../package.json"; import { defineConfig } from "tsup"; +import pkg from "../package.json"; + export default defineConfig({ name: pkg.name, sourcemap: false, minify: true, dts: true, clean: true, - replaceNodeEnv: true, + replaceNodeEnv: false, format: ["esm", "cjs"], outDir: "build", tsconfig: "./tsconfig.build.json", From 5703e0803ce610669f96c79ed39e5c97f183ffc5 Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Sun, 11 Dec 2022 04:14:26 +0100 Subject: [PATCH 4/6] authors fix --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2d24163..02f7c1c 100644 --- a/README.md +++ b/README.md @@ -93,7 +93,7 @@ export default handlePaths([{ ``` ## Authors -This library is created by Federico Vitale - (https://github.com/rawnly) +This library is created by Federico Vitale - ([@rawnly](https://github.com/rawnly)) ## License The MIT License. From 35fd2e2ea56d94fb7a7dfa1b04f01d83422008fa Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Sun, 11 Dec 2022 04:15:49 +0100 Subject: [PATCH 5/6] fixes --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 02f7c1c..a307e12 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ This allows you to easily manage and maintain your middlewares, and keep your ap ## Why This package was created based on [this discussion][discussion-link]. In the discussion, a user highlighted the difficulty to handle complex routing inside the -Next.js middleware. For instance having a `withAuth` middleware only for paths matching `/dashboard/:path*` and an i18n middleware on a subdomain. +Next.js middleware. For instance, you might want to have a `withAuth` middleware only for paths matching `/dashboard/:path*` and an `i18n` middleware on a subdomain. As of now, this can be archived via ugly path checking inside a middleware matching almost all the routes. With `next-wayfinder` I aim to add some ease until Next will support officially multiple middleware for different matchers. From 671e33ef0a2ae7c33bbcc88ea65e4b7bec32765c Mon Sep 17 00:00:00 2001 From: Federico Vitale Date: Sun, 11 Dec 2022 04:26:10 +0100 Subject: [PATCH 6/6] fixes --- README.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index a307e12..f3fed66 100644 --- a/README.md +++ b/README.md @@ -23,10 +23,10 @@ This allows you to easily manage and maintain your middlewares, and keep your ap ## Why This package was created based on [this discussion][discussion-link]. -In the discussion, a user highlighted the difficulty to handle complex routing inside the +In the discussion, a user highlighted the difficulty of handling complex routing inside the Next.js middleware. For instance, you might want to have a `withAuth` middleware only for paths matching `/dashboard/:path*` and an `i18n` middleware on a subdomain. -As of now, this can be archived via ugly path checking inside a middleware matching almost all the routes. -With `next-wayfinder` I aim to add some ease until Next will support officially multiple middleware for different matchers. +As of now, this can be achieved through ugly path checking inside a middleware that matches almost all the routes. +With `next-wayfinder` I aim to add some ease until Next officially supports multiple middleware for different matchers. ## Quick Start @@ -70,9 +70,8 @@ export default handlePaths([ ``` ### What if I want to check paths on subdomain? -In some cases you might want to check paths on a subdomain (ie using the same project for handling both public website and the dashboard). -This can be easily archived by passing as handler an array of middleware. This `handlePaths` iterates recursively all the items provided (even the nested ones) -so a very high level of complexity can be "handled". Anyway to improve performance I'd recommend to keep it as simple as possible. +In some cases, you might want to check paths on a subdomain (i.e., using the same project for handling both the public website and the dashboard). +This can be easily achieved by passing an array of middleware as a handler. The `handlePaths` function iterates recursively over all the items provided (including nested ones), so a very high level of complexity can be "handled". However, to improve performance, I would recommend keeping it as simple as possible. ```ts // middleware.ts