@produtype/core 1.8.0 → 1.8.2

package/dist/analyzer/catalogue.js

@@ -104,7 +104,20 @@ exports.JVM_DATABASES = [
 ];
 /** Ruby frameworks, read from the Gemfile. */
 exports.RUBY_BACKEND_FRAMEWORKS = [
-    ['rails', ['rails']],
+    /**
+     * Rails is often declared by its parts rather than by its name.
+     *
+     * Discourse's Gemfile has no `gem "rails"` in it at all: it pins `actionpack`,
+     * `actionview`, `activerecord` and `railties` separately, which is what a large
+     * application does when it wants to control the pieces. The report said
+     * `backend: ruby` — the fallback for a Gemfile with no web framework in it — about
+     * the best-known Rails application there is.
+     *
+     * `railties` is the framework itself and nothing but Rails and its engines depends
+     * on it; `actionpack` is the half that handles requests. Both are names the Rails
+     * team chose, which is the whole argument.
+     */
+    ['rails', ['rails', 'railties', 'actionpack']],
     ['sinatra', ['sinatra']],
     ['hanami', ['hanami']],
     ['roda', ['roda']],

package/dist/analyzer/detectEnv.js

@@ -104,10 +104,29 @@ async function detectEnv(ctx) {
         apiKey: [],
         unknown: [],
     };
-    const hasEnvExample = ctx.files.all.includes('.env.example');
+    /**
+     * The template has more than one spelling, and one exact string knew one of them.
+     *
+     * immich ships `docker/example.env` — the name reversed, and one directory down,
+     * which is where a compose deployment keeps it — and was told at `medium` that it
+     * reads environment variables without publishing a template. The check was
+     * `files.all.includes('.env.example')`: the right idea matched against a single
+     * literal at the root.
+     *
+     * The vocabulary is small and conventional, so it is written out: `.env` followed
+     * by example, sample, template, dist or defaults, the same words in front of `.env`
+     * instead, and the `.env.local.example` shape a monorepo uses per application.
+     *
+     * `.env` itself is deliberately not in it, and neither is `.env.production`: the
+     * first is the real file — a different finding when it is committed — and the second
+     * is one environment's values rather than a blank somebody fills in.
+     */
+    const ENV_TEMPLATE = /(^|\/)(?:\.?env(?:\.[a-z0-9-]+)?\.(?:example|sample|template|dist|defaults)|(?:example|sample|template)\.env)$/i;
+    const envTemplates = ctx.files.all.filter((file) => ENV_TEMPLATE.test(file));
+    const hasEnvExample = envTemplates.length > 0;
     const hasEnv = ctx.files.all.includes('.env');
-    if (hasEnvExample)
-        evidence.push({ type: 'file', value: '.env.example' });
+    for (const file of envTemplates.slice(0, 3))
+        evidence.push({ type: 'file', value: file, file });
     if (hasEnv)
         evidence.push({ type: 'file', value: '.env' });
     const sourceFiles = ctx.files.source;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "1.8.0",
+  "version": "1.8.2",
   "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": {