Gathering detailed insights and metrics for @dcefram/fs-routes
Gathering detailed insights and metrics for @dcefram/fs-routes
Gathering detailed insights and metrics for @dcefram/fs-routes
Gathering detailed insights and metrics for @dcefram/fs-routes
Create routes based on the file structure. Works with fastify, express, polkajs, or anything that has the same express-like syntax. Inspired by Next.js' approach for its routes.
npm install @dcefram/fs-routes
Typescript
Module System
Node Version
NPM Version
TypeScript (80.39%)
JavaScript (19.61%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
21 Commits
2 Watchers
1 Branches
1 Contributors
Updated on Nov 12, 2021
Latest Version
0.4.2
Package Id
@dcefram/fs-routes@0.4.2
Unpacked Size
13.44 kB
Size
5.08 kB
File Count
11
NPM Version
8.19.3
Node Version
18.13.0
Published on
Aug 28, 2023
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
7
Inspired by Vercel's Nextjs approach to pages. Also inspired by the "original" fs-router for Micro.
I initially made this for Polka, but it also worked for my newer fastify-based projects when that became a thing.
1npm i @dcefram/fs-routes
In your entry file where you created your fastify, polka, or express app:
1import Fastify from "fastify"; 2import fsRoutes from "@dcefram/fs-routes"; 3const fastify = Fastify({ logger: true }); 4 5fsRoutes(fastify, "/routes").listen(process.env.PORT, (error) => { 6 if (error) throw error; 7 8 console.log(`API Server running at port ${process.env.PORT}`); 9});
Folder structure of your app:
1your-app 2├── index.js # assuming that this is where you initialized your fastify app 3└── routes 4 └── user 5 ├── [slug] 6 │ ├── images.js 7 │ └── comments.js 8 └── [slug].js
Each routes file should have a module.exports
that exports an object that contains the handlers. Here's an example:
1const httpErrors = require("http-errors"); 2 3module.exports = { 4 get: (request, reply) => { 5 const { slug } = req.params; 6 reply.send({ slug }); 7 }, 8 put: (request, reply) => { 9 reply.send(httpErrors.NotImplemented()); 10 }, 11 delete: (request, reply) => { 12 reply.send(httpErrors.NotImplemented()); 13 }, 14};
It could also export the handlers using the ESM format:
1// OR export 2export function get(request, reply) { 3 const { slug } = req.params; 4 reply.send({ slug }); 5} 6 7export function put(request, reply) { 8 reply.send(httpErrors.NotImplemented()); 9} 10 11export function delete(request, reply) { 12 reply.send(httpErrors.NotImplemented()); 13}
With the folder structure above, you'll get the following endpoints:
1GET /user/:slug 2PUT /user/:slug 3DELETE /user/:slug 4GET /user/:slug/images # assuming that images.js has only `get` exported 5GET /user/:slug/comments # assuming that comments.js has only `get` exported 6 7### Ignore Files 8 9By default, fs-routes will ignore all files that is prefixed with an underscore (`_`). Example: 10 11```bash 12 13your-app 14├── index.js 15└── routes 16 └── user 17 ├── _helpers # This folder will be ignored 18 │ └── some-reusable-logic.js 19 ├── [slug] 20 │ ├── images.js 21 │ ├── comments.js 22 │ └── _utils.js # This file will be ignored 23 └── [slug].js
You can overwrite the ignore pattern, and supply it with your own. Example:
1import Fastify from "fastify"; 2import fsRoutes from "@dcefram/fs-routes"; 3 4const fastify = Fastify({ logger: true }); 5const ignorePattern = "\\.internal\\."; // Will ignore files and folders with ".internal." in its name 6 7fsRoutes(fastify, "/routes", { ignorePattern }).listen( 8 process.env.PORT, 9 (error) => { 10 if (error) throw error; 11 12 console.log(`API Server running at port ${process.env.PORT}`); 13 } 14);
I liked how easy it was to navigate through a Next.js-based project. But there are times that we simply want to ship a pure Node.js API without the frontend, and this is one of the building blocks that I made to make sure that I stay happy building the project.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 0/16 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
license file not detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
11 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More