@dunx/create-app 2.0.1 → 2.1.0

package/README.md

@@ -6,7 +6,7 @@ Scaffolds a new [dunx](https://github.com/petarzarkov/dunx) application.
 bunx @dunx/create-app my-api
 ```
 
-> `bun create dunx-app` does **not** work, and deliberately is not advertised:
+> `bun create dunx-app` does **not** work and is not advertised:
 > `bun create <template>` resolves the unscoped npm package
 > `create-<template>`, which this package - being scoped - is not.
 
@@ -44,7 +44,7 @@ and overwriting your copy of either is what `--force` is there to ask about.
 
 ## What it generates
 
-The `minimal` template, which is the same app as
+The `minimal` template, the same app as
 [`examples/minimal`](https://github.com/petarzarkov/dunx/tree/main/examples/minimal) a service, a controller, a module, `HttpFactory.create`, one test against a real
 server, and the `bunfig.toml` preload line that makes constructor injection work.
 
@@ -52,14 +52,15 @@ Its `src/` is a **byte-for-byte copy** of that example, and a test in this packa
 fails if the two ever drift. The example is the one CI boots, so keeping them
 identical is what makes the template trustworthy rather than merely plausible.
 
-## Two details worth knowing
+## Two details
 
-**Versions are resolved at run time, not written into the template.** Every
+**Versions are resolved at run time rather than written into the template.** Every
 `@dunx/*` range in the template manifest is `__DUNX_VERSION__`, replaced with a
 caret range on this package's own version. dunx versions in lockstep - every
 package shares one number and ships together - so the version doing the
-scaffolding is by definition a set that works together. Writing versions into the
-template would go stale on the next release.
+scaffolding is by definition a set that works together.
+
+Writing versions into the template would go stale on the next release.
 
 Keep it that way when you add a package later. The packages peer-depend on each
 other by caret range, so mixing minors warns on install - and can leave two copies

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dunx/create-app",
-  "version": "2.0.1",
+  "version": "2.1.0",
   "description": "Scaffold a new dunx application - bunx @dunx/create-app my-api",
   "keywords": [
     "bun",

package/templates/features/http/http.demo.ts

@@ -34,6 +34,11 @@ const postNote = (url: string, text: unknown): Promise<Response> =>
     body: JSON.stringify({ text }),
   });
 
+/**
+ * `203.0.113.7` stands in for whatever the caller put in the header itself, and
+ * `10.0.0.1` for the entry the one proxy in front of this app appended. With
+ * `trust proxy` set to one hop, only the second is worth anything.
+ */
 const whoami = async (url: string, forwarded: boolean): Promise<string> => {
   const response = await fetch(new URL('api/notes/whoami', url), {
     headers: forwarded ? { 'x-forwarded-for': '203.0.113.7, 10.0.0.1' } : {},
@@ -89,6 +94,8 @@ export class HttpDemo {
       `OPTIONS from https://evil.test -> ${denied.status} ${describeCors(denied)}`,
     );
 
+    // One trusted hop, so the last entry wins and the caller's own leftmost
+    // entry is ignored. Reaching past the proxy takes set('trust proxy', 2).
     logger.info(
       `set("trust proxy", true): X-Forwarded-For sent -> ${await whoami(url, true)}`,
     );