@bymax-one/nest-queue 1.0.0 → 1.0.2

package/CHANGELOG.md

@@ -7,6 +7,62 @@ versioning follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ---
 
+## [1.0.2] — 2026-07-30
+
+### Security
+
+- **Peer floors raised to exclude known-vulnerable NestJS versions.** The declared
+  ranges were `@nestjs/common ^11.0.0` and `@nestjs/core ^11.0.0`, and both
+  admitted versions with published advisories:
+
+  | Peer             | Advisory                                                                                                                                    | Vulnerable                    | New floor  |
+  | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ---------- |
+  | `@nestjs/common` | [GHSA-cj7v-w2c7-cp7c](https://github.com/advisories/GHSA-cj7v-w2c7-cp7c) — remote code execution via the `Content-Type` header              | `>= 11.0.0-next.1, < 11.0.16` | `^11.0.16` |
+  | `@nestjs/core`   | [GHSA-36xv-jgw5-4q75](https://github.com/advisories/GHSA-36xv-jgw5-4q75) — improper neutralization of special elements in downstream output | `<= 11.1.17`                  | `^11.1.18` |
+
+  A peer range is a statement about which versions this library supports. Leaving
+  the floor below a published advisory tells a consumer that a vulnerable install
+  is a supported one, and nothing in their tooling contradicts it.
+
+  Shipped as a **patch**, which is where a security fix belongs. Choosing a minor
+  would have bought nothing: `^1.0.1` — what a consumer almost always declares —
+  accepts `1.1.0` just as readily as `1.0.2`, so the same installs are affected
+  either way. Only a major would hold it back, and holding a security floor behind
+  a major migration is the opposite of what it is for.
+
+  No runtime behaviour changed, and the repository's own dev dependencies were
+  already above both floors. A consumer below them sees a peer warning telling
+  them to upgrade off a version with a published RCE advisory — which is the
+  intended outcome, not collateral damage.
+
+---
+
+## [1.0.1] — 2026-07-30
+
+First release published by CI, and therefore the first carrying an npm provenance
+attestation: `1.0.0` had to be published from a maintainer's machine because npm
+trusted publishing requires the package to already exist.
+
+### Documentation
+
+- Troubleshooting entry for `ERR_PNPM_IGNORED_BUILDS: msgpackr-extract` on
+  install. `msgpackr-extract` is a native optional dependency of BullMQ, and pnpm
+  blocks build scripts by default — pnpm 10 warns and installs anyway, pnpm 11
+  turns the same block into an error, so it appears on a pnpm upgrade with no
+  change on the consumer's side. The entry says whose dependency it is, shows both
+  the interactive and the declarative way to approve it, and notes that skipping
+  the build is fine because `msgpackr` falls back to a pure-JavaScript
+  implementation.
+
+### Internal
+
+- The dogfood smoke test installs its throwaway consumer with `--ignore-scripts`
+  and reports the full `spawnSync` outcome — status, signal, spawn error and both
+  streams — on failure. Not shipped in the package; recorded because it is what
+  made the `v1.0.0` release workflow fail after the publish had already succeeded.
+
+---
+
 ## [1.0.0] — 2026-07-30
 
 First public release. The library is feature-complete for the surface described
@@ -120,4 +176,6 @@ v6 peer range.
 
 ---
 
+[1.0.2]: https://github.com/bymaxone/nest-queue/releases/tag/v1.0.2
+[1.0.1]: https://github.com/bymaxone/nest-queue/releases/tag/v1.0.1
 [1.0.0]: https://github.com/bymaxone/nest-queue/releases/tag/v1.0.0

package/README.md

@@ -114,11 +114,11 @@ Both subpaths ship ESM **and** CommonJS with declarations for each format, so a
 
 ### Peer dependency matrix
 
-| Subpath      | Required peers                                                                                  |
-| ------------ | ----------------------------------------------------------------------------------------------- |
-| `.` (server) | `@nestjs/common ^11`, `@nestjs/core ^11`, `bullmq ^5.16`, `ioredis ^5`, `reflect-metadata ^0.2` |
-| `./shared`   | None                                                                                            |
-| Optional     | `bullmq-otel ^1` (OpenTelemetry)                                                                |
+| Subpath      | Required peers                                                                                            |
+| ------------ | --------------------------------------------------------------------------------------------------------- |
+| `.` (server) | `@nestjs/common ^11.0.16`, `@nestjs/core ^11.1.18`, `bullmq ^5.16`, `ioredis ^5`, `reflect-metadata ^0.2` |
+| `./shared`   | None                                                                                                      |
+| Optional     | `bullmq-otel ^1` (OpenTelemetry)                                                                          |
 
 ---
 
@@ -782,6 +782,39 @@ pnpm typecheck && pnpm test:types && pnpm lint && pnpm test:cov:all && \
 
 ## 🩺 Troubleshooting
 
+### `ERR_PNPM_IGNORED_BUILDS: msgpackr-extract` on install (pnpm 11)
+
+Installing this library with **pnpm 11** can stop with:
+
+```
+ERR_PNPM_IGNORED_BUILDS  Ignored build scripts: msgpackr-extract@3.0.4
+Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.
+```
+
+Nothing is wrong with your setup. `msgpackr-extract` is a native optional dependency
+of BullMQ, and pnpm blocks build scripts by default. **pnpm 10 warns and installs
+anyway; pnpm 11 turns the same block into an error**, which is why this appears on
+an upgrade with no change on your side. It is BullMQ's dependency, not this
+package's: this package ships zero runtime dependencies.
+
+Approve it once, either interactively:
+
+```bash
+pnpm approve-builds
+```
+
+or declaratively in your `pnpm-workspace.yaml`:
+
+```yaml
+onlyBuiltDependencies:
+  - msgpackr-extract
+```
+
+Skipping the build is also fine — `msgpackr` falls back to a pure-JavaScript
+implementation, so BullMQ still works, just without the native accelerator.
+
+---
+
 ### `CONNECTION_REQUIRES_NULL_RETRIES`
 
 This error fires in Mode A when the injected client was not configured with

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bymax-one/nest-queue",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "NestJS dynamic module wrapping BullMQ — typed jobs, flows, job schedulers, deduplication, OpenTelemetry, graceful shutdown",
   "author": "Bymax One <support@bymax.one>",
   "license": "MIT",
@@ -55,8 +55,8 @@
   },
   "dependencies": {},
   "peerDependencies": {
-    "@nestjs/common": "^11.0.0",
-    "@nestjs/core": "^11.0.0",
+    "@nestjs/common": "^11.0.16",
+    "@nestjs/core": "^11.1.18",
     "bullmq": "^5.16.0",
     "bullmq-otel": "^1.0.0",
     "ioredis": "^5.0.0",