Small fixes: dashboard #797

New issue

Open

opened 2026-10-11 07:14:54 +00:00 by claude · 1 comment

claude commented

2026-10-11 07:14:54 +00:00

Member

Compile warning at dashboard/jvm/src/infrastructure/BrowserSafetyHeaders.scala:26 ("the type test for cask.Response.Raw cannot be checked at runtime") — found during IW-681.
Vite/rolldown eval warning from htmx in the frontend build — found during IW-681.
In build.mill, name the dashboard.test directory once and build sources and the logging.properties path from it; LibraryLogLevelsTest could add one child logger name per library and an assertion message that names java.util.logging.config.file — project-management/issues/IW-681/review-phase-03-20261011-084838.md (style/composition/testing suggestions).

- [ ] Compile warning at `dashboard/jvm/src/infrastructure/BrowserSafetyHeaders.scala:26` ("the type test for cask.Response.Raw cannot be checked at runtime") — found during IW-681. - [ ] Vite/rolldown `eval` warning from htmx in the frontend build — found during IW-681. - [ ] In `build.mill`, name the `dashboard.test` directory once and build `sources` and the `logging.properties` path from it; `LibraryLogLevelsTest` could add one child logger name per library and an assertion message that names `java.util.logging.config.file` — project-management/issues/IW-681/review-phase-03-20261011-084838.md (style/composition/testing suggestions).

mph referenced this issue from a commit

2026-10-11 07:16:05 +00:00

chore(IW-681): file follow-ups as #795, #796 and #797

claude referenced this issue

2026-10-11 07:16:15 +00:00

IW-681: ./mill dashboard.test output is pristine #798

claude commented

2026-10-15 13:19:14 +00:00

Author

Member

Intake: needs-input
Workflow: diagnostic
Reason: G1 (1 CLARIFY marker)
Analysis: project-management/issues/IW-797/analysis.md on branch IW-797

1. How do we remove the htmx `eval` warning from the dashboard frontend build? (G1: an open decision in the analysis)

Each frontend build prints one rolldown [EVAL] warning. It comes from the debug helper htmx._ in htmx 2.0.11, which is the newest 2.x release. The dashboard does not call htmx._. Your rule forbids warnings in the code, and no earlier decision covers hiding a warning from a third-party library. The analysis is on branch IW-797: https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-797/project-management/issues/IW-797/analysis.md (section "Defect 2").

node_modules/htmx.org/dist/htmx.esm.js:870 — return eval(str)

a) Filter this one warning in dashboard/frontend/vite.config.js. The filter drops only the EVAL warning that comes from the htmx.org module, so an eval in our own code still prints a warning. The bundle does not change: the bytes are identical with and without the filter. You must approve this as an exception to the warnings rule.
b) Patch htmx with yarn patch so it uses an indirect eval. This removes the warning at its source. htmx._ then runs in global scope, and the patch must be carried again at each htmx upgrade.
c) Keep the warning and write the reason in the build docs. No code changes, but the build output is not clean, and a new warning is harder to see.

Recommended: a) — it is the smallest change, it does not alter third-party code, and any new eval still shows a warning.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input Workflow: diagnostic Reason: G1 (1 CLARIFY marker) Analysis: project-management/issues/IW-797/analysis.md on branch IW-797 ### 1. How do we remove the htmx `eval` warning from the dashboard frontend build? (G1: an open decision in the analysis) Each frontend build prints one rolldown `[EVAL]` warning. It comes from the debug helper `htmx._` in htmx 2.0.11, which is the newest 2.x release. The dashboard does not call `htmx._`. Your rule forbids warnings in the code, and no earlier decision covers hiding a warning from a third-party library. The analysis is on branch IW-797: https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-797/project-management/issues/IW-797/analysis.md (section "Defect 2"). > `node_modules/htmx.org/dist/htmx.esm.js:870` — `return eval(str)` - **a) Filter this one warning in `dashboard/frontend/vite.config.js`.** The filter drops only the `EVAL` warning that comes from the `htmx.org` module, so an `eval` in our own code still prints a warning. The bundle does not change: the bytes are identical with and without the filter. You must approve this as an exception to the warnings rule. - **b) Patch htmx with `yarn patch` so it uses an indirect eval.** This removes the warning at its source. `htmx._` then runs in global scope, and the patch must be carried again at each htmx upgrade. - **c) Keep the warning and write the reason in the build docs.** No code changes, but the build output is not clean, and a new warning is harder to see. **Recommended: a)** — it is the smallest change, it does not alter third-party code, and any new `eval` still shows a warning. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-15 13:19:14 +00:00