Render-gate bundle @ a443955858cc

Immutable render-gate bundle built from commit a443955. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

v0.3.0

• The companion-control mirrors are a knowledge file now, and gated. The
  render harness has to KNOW a control class before it can create a view that
  names one, so it booted metadata-only mirrors of the two bundled abap2UI5
  companion controls a view can name declaratively — written inline in
  lib/render.mjs, and the one mirror check-upstream did not compare. It
  rotted exactly the way the others did before they were gated: abap2UI5 added
  TokenKeyCell / TokenTextCells to MultiInputExt (the suggestion-row half
  of MultiInput.addValidator) and every view using them failed view
  CREATION here — which is worse than a property finding, because a
  downstream deviation can carry a property finding and cannot carry a dead
  document. The mirrors move to lib/cc-controls.mjs, the harness script is
  generated from that one source, and check-upstream compares each
  control's property names against app/webapp/cc/<Name>.js — in both
  directions, plus the case where the control is gone upstream and the mirror
  has no source any more.

• lib/released-api.mjs follows upstream's interface move. abap2UI5 put
  every type on the object that USES it — ty_s_get, ty_s_event_control and
  cs_device onto z2ui5_if_client, the three HTTP-config types onto
  z2ui5_if_ui5_exit — and retired the shared z2ui5_if_types into src/99
  together with z2ui5_if_exit, the exit interface's superseded name. The
  mirror still said the old thing, in both damaging directions at once:
  z2ui5_if_ui5_exit was reported as not released (correct code, flagged), and
  the two retired interfaces passed as released (an app naming them told
  nothing). They ship, so naming one compiles — which is exactly why it has to
  be reported, with the object the types moved to. Measured on
  abap2UI5/samples-controls app 252, which named z2ui5_if_types=>cs_device:
  the transpiled backend answered HTTP 500 because the retired interface's
  constants are not materialised there, and the corpus found it in an e2e
  sweep. The rule reports it statically now. The corpus is otherwise unchanged
  by the fix: 622 ports, 0 failing, before and after.

• scripts/check-upstream.mjs is published. The three hand-maintained
  mirrors in lib/ — formatters.mjs, frontend-actions.mjs,
  released-api.mjs — are compared against abap2UI5 weekly here, which is the
  wrong end of that contract: the pull request that renames a formatter or
  splits an action module is in the other repository, green, and nothing tells
  it. Nothing was broken by that yet only because the drift always surfaced
  within the week; the mirror check had already been broken once by an upstream
  refactor it could not see coming. Shipping the script lets abap2UI5 run the
  same comparison against its own working tree, on the change that moves the
  source — --local, the mode it already had. No second implementation, and
  nothing about the script's behaviour changes for this repository.

  Consumers can call it as
  node node_modules/@abap2ui5/linter/scripts/check-upstream.mjs --local <dir>;
  it exits 0 in sync, 1 on drift and 2 when the sources cannot be read, so a
  caller can treat unreachable sources as a skip rather than a failure.

Render-gate bundle @ 9c4c0c870005

Immutable render-gate bundle built from commit 9c4c0c8. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

Render-gate bundle @ 6828f9f1f32c

Immutable render-gate bundle built from commit 6828f9f. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

v0.2.2

• The render-runtime peer range forbade the pairing both READMEs prescribe.
  peerDependencies still said ^0.1.0 while the workspace had been released
  as 0.2.1 three times — and an out-of-range optional peer is not a quiet
  npm ls note, it is an ERESOLVE refusal, so
  npm i @abap2ui5/linter@0.2.1 @abap2ui5/render-runtime@0.2.1 failed outright
  and the stale 0.1 line was the only one npm would accept. It now reads
  ^0.1.0 || ^0.2.0: both published lines carry the same @openui5 pins
  (1.151.0, the version data/properties.json was generated from), so both
  genuinely run the render gate, and every consumer keeps installing — narrowing
  to the newest line alone would have broken the three repos sitting on 0.1.1
  for no compatibility reason. npm test now gates the range against the
  workspace's own version, since npm version --workspaces moves versions and
  no dependency range, which is exactly how this rotted unnoticed.

• ./rule-docs is a public export. The paragraph behind a rule id — what
  the defect is and what the fix looks like, the text the
  rules page is generated from — was
  reachable only by a reader with a browser. A consumer that hands findings to
  someone who has none (mcp-server's validate_view, talking to an agent) can now
  read RULE_DOCS through the exports map instead of citing a URL.

• Preview data, so a list stops photographing empty. The model behind a
  screenshot is derived from what the class seeds literally — that is all a
  static reconstruction can know — so a table filled by a SELECT renders as
  No data, which is most real apps. A <class>.mock.json next to the source
  is now used as preview data, by convention and without a flag, and
  --screenshot-model <file.json> says it explicitly. It is merged over
  the derived model rather than replacing it: the derived one knows every field
  of every declared structure, which is what makes the remaining bindings
  resolve, so a two-line mock file can fill one table without restating the
  class's whole model. A mock file that does not parse is reported next to the
  picture it did not fill — silently going back to an empty table is the one
  failure nobody would investigate.

• --screenshot-size takes a list. --screenshot-size 390x844,1280x900
  renders both in ONE browser session and writes them side by side, viewport in
  the file name. The launch and the UI5 boot cost more than every render put
  together, so a device matrix is barely more expensive than a single picture —
  and responsive layout is precisely what nobody has in their head.

• The Action can photograph what it checked. screenshots: build/screenshots
  (with screenshot-size and screenshot-theme beside it) renders every
  checked view into a directory for the workflow to upload as an artifact or
  post on the pull request — the review artefact CI could not produce before,
  because seeing an abap2UI5 view needed a system. It runs whether the check
  passed or failed, since the run that failed is the one where a reviewer most
  wants to look at the view, and a view that cannot be photographed is a
  warning rather than a second reason to fail the job.

• --screenshot: see the view, without a system. An abap2UI5 view exists
  at runtime and nowhere else, so looking at one has meant activating the class
  on a system and launching the app. The render gate has been loading these
  views in a real browser all along — it just threw each one away the moment it
  knew the view survived creation. Now it can keep it:

  abap2ui5lint zcl_my_app.clas.abap --screenshot app.png
  

  The view is reconstructed from the builder calls, seeded with the model
  derived from the class's own TYPES/DATA, rendered against the local
  OpenUI5 runtime and written as a PNG — the same reconstruction the gate
  clears, in the theme (--screenshot-theme) and viewport (--screenshot-size,
  e.g. 390x844) you name. It is a mode: nothing else runs, and stdout carries
  the written paths and nothing else, so an editor or a workflow can read them
  straight. Render errors do not suppress the picture — a view with one broken
  binding still comes up, and the half that rendered is the part worth seeing.

  Two things had to be true for a picture to be worth taking. The themes ship
  as .less in the @openui5 sources and never as the library.css a browser
  asks for, so unstyled UI5 was all the gate had ever rendered; a screenshot
  session compiles the theme the way the UI5 build does (less-openui5, now in
  the render runtime), on demand and cached per runtime version and theme. And
  a sap.m.Page lays its content out absolutely against the height of its
  container, so in the gate's container — which never needed one — the picture
  came back as a header over an empty area, with the whole view present in the
  DOM and every check passing. Both are fixed where they belong, in the
  harness, which now also mirrors the body abap2UI5 itself serves
  (sapUiBody sapUiSizeCompact) so the content density in the picture is the
  content density on the system.

  The gate is untouched by all of it: it asks for no stylesheet, compiles
  nothing, and less-openui5 is deliberately outside RENDER_DEPS so a
  missing theme compiler can never stop a check from running. screenshotFiles
  is the library form, returning buffers rather than writing files.

Render-gate bundle @ 918ff0229abb

Immutable render-gate bundle built from commit 918ff02. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

Render-gate bundle @ 77620af03238

Immutable render-gate bundle built from commit 77620af. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

Render-gate bundle @ 627ab6b51295

Immutable render-gate bundle built from commit 627ab6b. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

Render-gate bundle @ 4b32178c4433

Immutable render-gate bundle built from commit 4b32178. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.

Render-gate bundle @ 3b98c3095674

Immutable render-gate bundle built from commit 3b98c30. Preferred by VS Code extension builds pinning this linter commit; the rolling render-gate-bundle release always carries the newest build.