Config Validator

Features

• package.json: JSON syntax, package-name rules (capitals and spaces are refused by npm), version form, dependency ranges, and missing license / description / repository
• `.env`: duplicate keys (listing every line they appear on — three occurrences means three lines), dots and hyphens in key names, empty values, stray quotes around values
• ⚠️ `.env` key casing: a name that is not upper-case is only a suggestion; two keys that differ only in case (DATABASE_URL versus database_url) is raised to a warning, with the platform difference spelled out — Windows lets them overwrite each other, while Linux / macOS treats them as two independent variables
• robots.txt: `Disallow: /` blocking the whole site, an empty `Disallow:` that means the opposite, a Sitemap that is not absolute, a missing User-agent
• ⚠️ robots.txt can test a path: give a path and one or more crawlers (one per line, commas fine) and it says allowed or blocked for each, naming the rule that won and why (the most specific group wins, then the longest match, then Allow on a tie, with `*` and `$` support)
• sitemap.xml: the namespace declaration, relative `<loc>` values, duplicates, and the 50,000-URL / 50 MB limits
• ⚠️ sitemap understands both root elements: `<urlset>` (listing pages) and `<sitemapindex>` (listing other sitemap files). Mixing the root with the wrong child — a `<url>` inside an index, or the reverse — makes crawlers read nothing at all, so it is reported separately
• ⚠️ `.env` can find unreferenced keys: paste the code that reads the file and it lists the keys that never appear. It is a text search (with word boundaries, so `DATABASE_PORT` does not make `PORT` count as used): `process.env.X`, `process.env['X']` and destructuring `const { X } = process.env` are all caught, but dynamic reads (`process.env[name]`, an assembled key) are not — so a hit is not proof a key is dead, and silence is not proof it is used
• HTTP headers: deprecated X-XSS-Protection / Expect-CT / HPKP, plus missing CSP, HSTS, nosniff and friends
• ⚠️ Findings are split into errors (broken) / warnings (runs, but probably not what you meant) / suggestions (could be better) and ranked in that order
• ⚠️ `Access-Control-Allow-Origin: *` with `Allow-Credentials: true` is rejected outright by browsers, and is reported as an error
• ⚠️ Every finding gives the reason — not “non-compliant”, but what breaks if you leave it
• Detects which kind of file you pasted, and lets you override it
• Runs entirely in your browser; nothing is uploaded or stored

How to use

1. Paste the config; the type is detected automatically
2. Override the type in the options if the guess is wrong
3. Read the findings errors → warnings → suggestions, each with its reason

FAQ

Why three levels rather than pass/fail?

Because a pass/fail validator hands you a wall of failures with no order to them, and people stop reading and ignore all of it — which is exactly how a validator stops being useful. Here, “errors” are what gets the file rejected (malformed JSON, a relative `<loc>`, that CORS pair, the same key written twice), “warnings” run but are probably not what you meant (`Disallow: /` blocking everything, two env keys differing only in case), and “suggestions” are improvements (a missing license, a key name that is not upper-case). Ranked this way, the first thing to fix is obvious.

Why is an empty `Disallow:` a finding?

Because an empty value and a slash differ by one character and mean the opposite of each other: `Disallow:` means allow everything, `Disallow: /` means block the entire site. It is the easiest thing to get backwards in robots.txt, and getting it backwards is silent on both sides — one way search engines quietly stop coming, the other way a staging rule nobody removed costs you all your organic traffic after launch.

Why is a duplicated env key an error rather than a hint?

Because most loaders (dotenv, Docker, systemd) take the later value, while writing a key twice usually means you wanted that value to win — so the copy you edited is the one being ignored, and it is invisible while debugging: the file plainly shows the value you want and the program reads another. It ranks among the top causes of real incidents, so it is reported as an error, listing every line the key appears on (three occurrences means three lines): knowing “it is duplicated” is not enough, you need to know which copies to delete.

DATABASE_URL and database_url are two different keys — why are they flagged?

Because on Windows they are not two keys. Windows treats environment-variable names case-insensitively, so two keys that differ only in case overwrite each other (which one wins depends on load order), while on Linux / macOS they are two independent variables. The same `.env` therefore behaves differently on the two systems — fine on your Mac, wrong on Windows CI — which makes it one of the hardest bugs to track down. So it is its own warning, naming both keys and their line numbers. It is kept separate from “the name is not upper-case”, which is only a suggestion because a lone lower-case name works on either platform.

Can the “unreferenced keys” check miss or over-report?

Both, because it is a text search, not a parse. It catches `process.env.X`, `process.env['X']` and destructuring `const { X } = process.env` (the key name appears as text), but not a dynamic read like `process.env[name]` or an assembled key — that key gets listed as unreferenced, which is an over-report. Conversely, the key name appearing in a comment or an unrelated string counts as a use, which is an under-report. So “not listed” does not mean safe to delete, and “listed” does not mean it is dead: treat it as a lead and search the whole repository first.

Why is the dependency-range check so lenient?

Because a `dependencies` value can be `workspace:*`, `file:../x`, a git URL, an `npm:` alias, or a space-separated comparator set like `>=1.0.0 <2.0.0`. Judging that grammar in full means pulling in a semver library, and the goal here is not semantic validation — it is catching the obvious typos (an empty string, `^abc`, `1.0.0.0`). Every finding asks the reader to edit a config file, so a false positive costs this tool its credibility.

Does it read my secrets?

No. Everything runs in the browser, nothing is uploaded or stored. It also looks only at syntax and structure: what follows `API_KEY=` has no bearing on whether the key name is valid or whether the file repeats a key, so no value is ever inspected.