@produtype/core 1.11.0 → 1.12.0

package/dist/analyzer/detectDeployment.js

@@ -30,7 +30,21 @@ async function detectDeployment(ctx) {
         || f.startsWith('.github/workflows/')
         || /(^|\/)(\.gitlab-ci\.yml|\.circleci\/config\.yml|azure-pipelines\.yml|Jenkinsfile|\.woodpecker\.ya?ml)$/i.test(f)
         || /(^|\/)(k8s|kubernetes|helm|deploy|\.platform)\//i.test(f));
-    for (const f of presentFiles.slice(0, 20))
+    /**
+     * The container the editor opens is not a deployment artifact.
+     *
+     * 1.9.0 taught `docker.presence` that `.devcontainer/` is the Development Containers
+     * convention — the environment a *contributor* works in — and left this detector
+     * believing it. atuin's deployment evidence opened with `.devcontainer/Dockerfile`,
+     * so "how does this ship" was answered with how it is developed, in the same report
+     * that the other detector got right.
+     *
+     * Only where something else is present: a repository whose only container
+     * definition is its devcontainer keeps it rather than losing the answer.
+     */
+    const shipped = presentFiles.filter((f) => !/(^|\/)\.devcontainer\//.test(f));
+    const cited = shipped.length > 0 ? shipped : presentFiles;
+    for (const f of cited.slice(0, 20))
         evidence.push({ type: 'file', value: f });
     const hits = await (0, textSearch_1.searchInFiles)(ctx.root, ctx.files.source, [
         /SIGTERM/i, /SIGINT/i,
@@ -80,7 +94,7 @@ async function detectDeployment(ctx) {
         complete: prodAware,
         evidence: (0, absenceEvidence_1.evidenceOrFileNameSearch)(evidence, 'anything that says how this is deployed', ['Dockerfile', 'docker-compose', '.github/workflows/', 'Procfile', 'fly.toml', 'render.yaml', 'NODE_ENV', 'RAILS_ENV', 'ASPNETCORE_ENVIRONMENT', 'a file naming production']),
         details: {
-            dockerArtifacts: presentFiles.some((f) => /Dockerfile|compose/.test(f)),
+            dockerArtifacts: cited.some((f) => /Dockerfile|compose/.test(f)),
             ci: presentFiles.some((f) => f.startsWith('.github/workflows/')),
             gracefulShutdown: graceful,
             /** False where the runtime hands each request to a worker that exits on its own. */

package/dist/analyzer/detectGdpr.js

@@ -61,6 +61,23 @@ async function detectGdpr(ctx) {
          */
         /gdpr[_\- ]?(delete|deletion|eras|removal|forget)/i,
         /(delete|deletion|eras|removal)[_\- ]?gdpr/i,
+        /**
+         * A DELETE on the caller's own account, which is what article 17 asks for.
+         *
+         * The note below records that `deleteUser(id)` was measured and withdrawn —
+         * delete is every admin screen ever written. A route is not that call. atuin's
+         * server declares `.route("/account", delete(handlers::user::delete))` and was
+         * told it has no erasure flow at all; the difference between that and an admin
+         * screen is in the path, which says whose account is being removed.
+         *
+         * `DELETE` is HTTP's word and `/account`, `/users/me` and `/me` are the
+         * conventional first-person paths. `/accounts/:id` does not match: the boundary
+         * after `account` fails on the plural, which is the admin case this must keep
+         * out.
+         */
+        /\bdelete\s*[(:]\s*["'`]\/?(?:account\b|users?\/me\b|me\b)/i,
+        /@Delete\(\s*["'`]\/?(?:account\b|users?\/me\b|me\b)/i,
+        /\.route\(\s*["'`]\/?(?:account\b|users?\/me\b|me\b)[^)]*,\s*delete\(/i,
     ], 20);
     /**
      * `deleteUser(id)` is not article 17 — it is every admin screen ever written, and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "1.11.0",
+  "version": "1.12.0",
   "description": "Deterministic CLI and library that analyzes a web application repository and reports how far it is from production-ready for the kind of product it is meant to be.",
   "license": "MIT",
   "bin": {