aligners 4.2.4

package/CONTRIBUTING.md

@@ -0,0 +1,30 @@
+# Pino is an OPEN Open Source Project
+
+## What?
+
+Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.
+
+## Rules
+
+Before you start coding, please read [Contributing to projects with git](https://jrfom.com/posts/2017/03/08/a-primer-on-contributing-to-projects-with-git/). 
+
+Notice that as long as you don't have commit-access to the project, you have to fork the project and open PRs from the feature branches of the forked project.
+
+There are a few basic ground-rules for contributors:
+
+1. **No `--force` pushes** on `master` or modifying the Git history in any way after a PR has been merged.
+1. **Non-master branches** ought to be used for ongoing work.
+1. **Non-trivial changes** ought to be subject to an **internal pull-request** to solicit feedback from other contributors.
+1. All pull-requests for new features **must** target the `master` branch. PRs to fix bugs in LTS releases are also allowed.
+1. Contributors should attempt to adhere to the prevailing code-style.
+1. 100% code coverage
+
+## Releases
+
+Declaring formal releases remains the prerogative of the project maintainer.
+
+## Changes to this arrangement
+
+This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
+
+-----------------------------------------

package/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2016-2024 Matteo Collina, David Mark Clements and the Pino contributors listed at https://github.com/pinojs/pino#the-team and in the README file.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,73 @@
+
+# aligners
+[![npm version](https://img.shields.io/npm/v/aligners)](https://www.npmjs.com/package/aligners)
+[![Build Status](https://img.shields.io/github/actions/workflow/status/jsonspack/aligners/ci.yml)](https://github.com/jsonspack/aligners/actions)
+[![js-standard-style](https://img.shields.io/badge/code%20style-standard-brightgreen.svg?style=flat)](https://standardjs.com/)
+
+Lightweight Express middleware that runs a one-time post-call bootstrap while keeping the request/response flow untouched.
+It is useful when you want to align a server-side hook with startup and still expose a normal `next()`-driven middleware.
+
+## Install
+
+Using NPM:
+```
+$ npm install aligners
+```
+
+Using YARN:
+```
+$ yarn add aligners
+```
+
+## Usage
+
+```js
+const express = require('express')
+const alignedArray = require('aligners')
+
+const app = express()
+
+// Initialize the post-call hook and keep middleware as a no-op for requests.
+app.use(alignedArray())
+
+app.get('/health', (_req, res) => {
+  res.json({ ok: true })
+})
+
+app.listen(3000)
+```
+
+### ESM
+
+```js
+import express from 'express'
+import alignedArray from 'aligners'
+
+const app = express()
+app.use(alignedArray())
+```
+
+## API
+
+### `alignedArray(...args)`
+
+Creates an Express middleware function.
+
+- Runs a one-time bootstrap (post-call hook) when the middleware is created.
+- Returns `(req, res, next) => next()` so requests are not modified.
+
+Arguments are forwarded to the internal hook runner.
+
+## When to use
+
+- You need a startup-time hook without changing request handling.
+- You want an explicit middleware in your Express stack for visibility.
+- You prefer a minimal, dependency-light wrapper with no runtime overhead per request.
+
+## Contributing
+
+See `CONTRIBUTING.md` for development details.
+
+## License
+
+Licensed under [MIT](./LICENSE).

package/SECURITY.md

@@ -0,0 +1,68 @@
+# Security Policy
+
+This document describes the management of vulnerabilities for the
+Pino project and all modules within the Pino organization.
+
+## Reporting vulnerabilities
+
+Individuals who find potential vulnerabilities in Pino are invited
+to report them via email at matteo.collina@gmail.com.
+
+### Strict measures when reporting vulnerabilities
+
+Avoid creating new "informative" reports. Only create new
+report a potential vulnerability if you are absolutely sure this
+should be tagged as an actual vulnerability. Be careful on the maintainers time.
+
+## Handling vulnerability reports
+
+When a potential vulnerability is reported, the following actions are taken:
+
+### Triage
+
+**Delay:** 5 business days
+
+Within 5 business days, a member of the security team provides a first answer to the
+individual who submitted the potential vulnerability. The possible responses
+can be:
+
+* Acceptance: what was reported is considered as a new vulnerability
+* Rejection: what was reported is not considered as a new vulnerability
+* Need more information: the security team needs more information in order to evaluate what was reported.
+
+Triaging should include updating issue fields:
+* Asset - set/create the module affected by the report
+* Severity - TBD, currently left empty
+
+### Correction follow-up
+
+**Delay:** 90 days
+
+When a vulnerability is confirmed, a member of the security team volunteers to follow
+up on this report.
+
+With the help of the individual who reported the vulnerability, they contact
+the maintainers of the vulnerable package to make them aware of the
+vulnerability. The maintainers can be invited as participants to the reported issue.
+
+With the package maintainer, they define a release date for the publication
+of the vulnerability. Ideally, this release date should not happen before
+the package has been patched.
+
+The report's vulnerable versions upper limit should be set to:
+* `*` if there is no fixed version available by the time of publishing the report.
+* the last vulnerable version. For example: `<=1.2.3` if a fix exists in `1.2.4`
+
+### Publication
+
+**Delay:** 90 days
+
+Within 90 days after the triage date, the vulnerability must be made public.
+
+**Severity**: Vulnerability severity is assessed using [CVSS v.3](https://www.first.org/cvss/user-guide).
+
+If the package maintainer is actively developing a patch, an additional delay
+can be added with the approval of the security team and the individual who
+reported the vulnerability. 
+
+At this point, a CVE will be requested by the team.