{
  "id": "p_2X0T0UelgTp2j50D",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_2X0T0UelgTp2j50D",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apievangelist"
  },
  "body": "A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: \"Aliases: the hidden gem in OpenLint,\" Kin Lane, October 30, 2026, https://openlint.org/blog/2026/10/30/aliases-hidden-gem/\n\nMarisol read the post on a Friday afternoon, in the gap between a failed build and the standup she was avoiding. She maintained the API ruleset for her company's logistics platform, and she was the only person on the team who could read a JSONPath expression without squinting.\n\nThe post opened with her own complaint. Deciding what a rule should check was the easy part, and the path was the hard part. She had pasted the same eight-method bracket into four rules and had never liked it.\n\nShe read the two versions side by side, the one with the path repeated and the one with a name. The line that landed was this: \"Now the rule reads as what it means: every operation needs a summary.\" She thought of the new hire who had asked last month what the second half of a given line meant. She had said she'd explain it later, and she hadn't.\n\nThen she got to the part about OpenAPI 3.2. The post said that version \"added a query method\", and that the copied path wouldn't select it, so an operation using it would pass both rules unchecked. Her stomach tightened a little. She had no idea whether any of her paths mentioned query. She opened her ruleset in another window and searched. None did. Nobody had used it yet, as far as she knew, but the rules wouldn't have told her if someone had. The post said it had tried this on a real document: \"We tried it: the same document went from no problems to two.\" Two problems that had been invisible was not a number she enjoyed thinking about for her own estate.\n\nShe was less comfortable with the Servers section. Five paths for one name looked like a lot of ceremony, and her first instinct was that she'd rather write the short recursive path and accept some noise. But the post had already answered that. A recursive path would also match a property called servers inside a schema or an example, and she remembered a rule of hers firing on an example payload last spring. She had blamed the example, not the path.\n\nWhat bothered her most was near the end. The post was straight about it: \"The big one is that an alias belongs to the ruleset that declares it.\" Her team extended a shared base ruleset, and the post said plainly that extending one doesn't let your rules use its aliases. So she would copy what she needed, as everyone did. She didn't love hearing that the sharing problem was unsolved. She also noticed it was in the post's own limits section, not buried, and that it pointed to an open discussion. That made her trust the rest slightly more.\n\nShe didn't rewrite the ruleset. She didn't touch the servers rule or think about the scoped version for Swagger 2.0, which her company no longer had.\n\nShe did the thing the last paragraph asked: \"Next time you paste a path into a second rule, make it an alias.\" She picked the four rules sharing the bracket path, moved it under a single alias, and ran the linter against her largest spec before and after. The output matched line for line.\n\nThen she wrote a note in the team's channel saying the path now lived in one place and that she'd check later whether query belonged on that line.\n\nShe closed the tab and went to standup.",
  "title": "Fiction: A reader of \"Aliases: the hidden gem in OpenLint\"",
  "topics": [
    "openlint",
    "api-linting",
    "open-source",
    "fiction"
  ],
  "published_at": "2026-10-30T18:24:30.664Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}