abap2ui5lint.jsonc

{
  // abap2UI5-linter — validates a whole app class without an SAP system:
  // the ABAP and the view it produces, together. Not a view checker: of its
  // five rule groups (metadata, structure, version, data, abap2ui5) the last
  // one is about the relationship between the ABAP class and the view it
  // builds — defects that stay silent at runtime and that no UI5 tooling can
  // see. See https://github.com/abap2UI5/linter
  "$schema": "./node_modules/@abap2ui5/linter/data/abap2ui5lint.schema.json",

  "paths": ["src"],

  // The samples must run on the oldest release abap2UI5 supports, so the
  // property gate uses the same 1.71 floor as the rest of the project.
  "ui5": "1.71",
  "distribution": "openui5",

  // The render gate is REQUIRED here, not merely left on. It is on by default,
  // and a default-on gate whose runtime is missing steps aside for the property
  // gate and the run stays green - a corpus that claims every view loads should
  // not be able to pass without having loaded them. Saying so makes a missing
  // @abap2ui5/linter-render (the render runtime, render-runtime up to 0.7.0)
  // an error instead.
  "render": true,

  // The two README badges. Every run rewrites these shields.io endpoint
  // files, and they are two because they say two different things:
  //
  //   abap2UI5       | 32 apps - 37 views - 828 controls   what is here
  //   check-abap2UI5 | 84 rules passed                     what CI made of it
  //
  // check-abap2UI5 publishes them from main to the `badges` branch, which the
  // README reads; here they are regenerated by every run and not committed.
  // Together they say something a workflow badge cannot: a green workflow
  // means "the job exited zero", which is also true of a run that found
  // nothing checkable at all - and that run prints "nothing checkable", grey,
  // on both. Same setup as abap2UI5/samples.
  "badge": [
    { "kind": "corpus", "file": ".github/badges/abap2ui5.json" },
    { "kind": "checks", "file": ".github/badges/check-abap2ui5.json" }
  ],

  // src/02 is the Smart Controls package, and its README says so: sap.ui.comp
  // driven by OData metadata, SAPUI5 + an activated Gateway service. Those
  // samples exist to show a SAPUI5-only technology, so on the OpenUI5 setting
  // above the whole folder reports itself, three times over:
  //
  //   * sapui5-only-control  — the point of the package
  //   * unknown-aggregation  — a knock-on: sap.ui.comp is not in the metadata
  //     snapshot, so an aggregation under a smart control cannot be resolved
  //     and is attributed to the nearest control that IS known (sap.m.Page).
  //     The chains themselves are correct — controlConfiguration really does
  //     sit under SmartFilterBar.
  //     DELETED on the 0.2.0 bump, as its expiry said. Re-measured first: with
  //     the pin at 0.2.0 and the line gone, this repository reports ZERO
  //     unknown-aggregation findings. The line was hiding a linter defect, and
  //     the defect is fixed. The other two exclusions stay, they are facts
  //     about SAPUI5
  //   * render-error         — the render gate serves the OpenUI5 runtime,
  //     which has no sap/ui/comp/... modules to load
  //
  // Excluded per rule rather than by flipping "distribution" to sapui5, so
  // every other package keeps being checked against the OpenUI5 landscape it
  // is meant to run on.
  "rules": {
    // The house layout of a view-builder chain: one call per line, four
    // spaces per level of the tree, `end( )` alone in the column of the
    // `ele( )` it closes. Opt-in by design (OPT_IN in the linter's
    // findings.mjs), because it encodes ONE style — the one defined in
    // abap2UI5 (docs/agents/building-apps.md, "Formatting the chain") and
    // already enabled there, so the samples a reader copies from are laid
    // out the way the framework's own apps are. `npm run fmt:chains`
    // applies it; the rewrite is verified whitespace-only, so it can never
    // change what the view builds.
    //
    // It also subsumes chain-element-per-line, which only ever covered the
    // first of those four rules and stays on underneath as a hint.
    "chain-house-layout": { "severity": "warning" },

    "sapui5-only-control": { "exclude": ["/src/02/"] },
    // A render error carries no line, so a source directive cannot reach it —
    // the config is the only instrument. Besides src/02 (the Smart Controls
    // package, above) one shape here, about what the static harness can serve
    // rather than about the app:
    //
    //   * src/03 + src/04 (RAP) bind an ObjectStatus `state` to a CDS entity
    //     field. The field has no ABAP declaration to read a type from, so the
    //     mock model seeds '' and strict validation rejects it as a ValueState
    //     — the running app gets Success/Warning/Error from the entity
    //
    // App 489 (abap2UI5's companion control z2ui5/cc/Websocket) left this
    // list with @abap2ui5/linter 0.8.2, whose harness carries a stand-in for
    // every live companion control. In src/02, 314 renders clean as well - it
    // shows the OData model switch, no sap.ui.comp control - so the linter
    // notes its waiver as stale; the folder stays excluded as a whole, as the
    // package it is.
    "render-error": {
      "exclude": [
        "/src/02/",
        "/src/03/z2ui5_cl_smps_app_005\\.",
        "/src/04/z2ui5_cl_smps_app_(006|010)\\."
      ]
    }
  },

  "failOn": "warning"
}