Gathering detailed insights and metrics for exegesis-express
Gathering detailed insights and metrics for exegesis-express
Gathering detailed insights and metrics for exegesis-express
Gathering detailed insights and metrics for exegesis-express
npm install exegesis-express
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
57 Stars
126 Commits
4 Forks
3 Watching
22 Branches
2 Contributors
Updated on 24 Oct 2024
Minified
Minified + Gzipped
TypeScript (53.46%)
JavaScript (46.54%)
Cumulative downloads
Total Downloads
Last day
-0.9%
86,145
Compared to previous day
Last week
3%
457,717
Compared to previous week
Last month
9.7%
1,921,135
Compared to previous month
Last year
8.6%
20,603,077
Compared to previous year
exegesis
n. An explanation or critical interpretation of a text, especially an API definition document.
-- No dictionary ever
This library implements an Express middleware for OpenAPI 3.x.
Check out the tutorial here.
Calling exegesisExpress.middleware(openApiFile, options)
will return a Promise
which resolves to a connect/express middleware (alternatively you can call
exegesisExpress.middleware(openApiFile, options, done)
, if callbacks are your
thing).
openApiFile
is either a path to your openapi.yaml or openapi.json file,
or it can be a JSON object with the contents of your OpenAPI document. This
should have the x-exegesis-controller
extension defined on any paths you want to be able to access.
options
can be anything you can pass to exegesis. At a
minimum, you'll probably want to provide options.controllers
, a path to where
your controller modules
can be found. If you have any security requirements defined, you'll also
want to pass in some authenticators.
To enable response validation, you'll want to provide a validation callback
function via onResponseValidationError()
.
Exegesis's functionality can also be extended using plugins,
which run on every request. Plugins let you add functionality like
role base authorization,
or CORS.
Exegesis-express should appear near the top of your middleware stack, before
any body parsers. This is because exegesis will take care of parsing the body
for you, and it can't do that if the body has already been read. If you put
a body parser ahead of exegesis-express, exegesis will try to use req.body
if it's there.
OpenAPI 3.x lets you specify what servers your API is available on. For example:
1servers: 2 - url: "/api/v2"
By default, exegesis will take 'servers' into account when routing requests, so if you have the above servers section, and a path in your API called "/users", then exegesis will only match the route if the incoming requests has the URL "/api/v2/users".
If you have path templates in your servers, the variables will be available to
your controllers via context.params.server
.
If you specify the ignoreServers
option, however, exegesis will ignore the
servers section, an route purely based on your paths. This lets you do
something like:
1const exegesisMiddleware = await exegesisExpress.middleware( 2 path.resolve(__dirname, "./openapi.yaml"), 3 { ignoreServers: true } 4); 5app.use("/api/v2", exegesisMiddleware);
which means non-api paths will not even be sent to the exegesis middleware.
1import express from "express"; 2import path from "path"; 3import http from "http"; 4import * as exegesisExpress from "exegesis-express"; 5 6async function createServer() { 7 // See https://github.com/exegesis-js/exegesis/blob/master/docs/Options.md 8 const options = { 9 controllers: path.resolve(__dirname, "./controllers"), 10 }; 11 12 const exegesisMiddleware = await exegesisExpress.middleware( 13 path.resolve(__dirname, "./openapi.yaml"), 14 options 15 ); 16 17 const app = express(); 18 19 // If you have any body parsers, this should go before them. 20 app.use(exegesisMiddleware); 21 22 app.use((req, res) => { 23 res.status(404).json({ message: `Not found` }); 24 }); 25 26 app.use((err, req, res, next) => { 27 res.status(500).json({ message: `Internal error: ${err.message}` }); 28 }); 29 30 const server = http.createServer(app); 31 server.listen(3000); 32}
Copyright 2018 Jason Walton
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
Found 2/15 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-25
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