Consider trimming endOfLine from the JS formatting options panel (no visible effect in browser-only playground) #79

New Issue

2026-05-06T05:01:19Z

spikerj commented

2026-05-06 05:01:19 +00:00

Observation (not a bug)

The formatting options popover exposes endOfLine: lf | crlf | auto as a <select>. Prettier respects the value when formatting, but a browser-only playground that renders the formatted source straight back into Monaco gives the learner no perceivable signal of what changed — Monaco displays line endings agnostically.

Result: a learner toggles the option, clicks Format Now, sees the same screen, concludes the toggle is broken / they don’t understand it. That’s the opposite of the educational goal of the panel.

Options

Remove the field from the visual panel. Keep the store option (advanced sandbox .prettierrc editors can still set it; defaults remain lf). Simplest fix.
Keep it and add a hint that the setting only matters if you copy the formatted code into a text editor. Educational but adds clutter.
Defer the decision until a copy-to-clipboard / save-as-file affordance ships, at which point endOfLine would have visible effect.

Proposal: option 1 (remove from panel, leave in store). Easiest to reverse if a copy-to-clipboard feature later reintroduces the demand.

Owner pointers

libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.html (the End of line <label> block, lines ~167-184)
libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.ts:76 (endOfLineOptions, setEndOfLine)
The store side (prettier-config.store.ts) keeps the endOfLine field unchanged.

## Observation (not a bug) The formatting options popover exposes `endOfLine: lf | crlf | auto` as a `<select>`. Prettier respects the value when formatting, but a browser-only playground that renders the formatted source straight back into Monaco gives the learner no perceivable signal of what changed — Monaco displays line endings agnostically. Result: a learner toggles the option, clicks Format Now, sees the same screen, concludes the toggle is broken / they don’t understand it. That’s the opposite of the educational goal of the panel. ## Options 1. **Remove the field from the visual panel.** Keep the store option (advanced sandbox `.prettierrc` editors can still set it; defaults remain `lf`). Simplest fix. 2. **Keep it and add a hint** that the setting only matters if you copy the formatted code into a text editor. Educational but adds clutter. 3. **Defer the decision** until a copy-to-clipboard / save-as-file affordance ships, at which point `endOfLine` would have visible effect. Proposal: option 1 (remove from panel, leave in store). Easiest to reverse if a copy-to-clipboard feature later reintroduces the demand. ## Owner pointers - `libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.html` (the End of line `<label>` block, lines ~167-184) - `libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.ts:76` (`endOfLineOptions`, `setEndOfLine`) - The store side (`prettier-config.store.ts`) keeps the `endOfLine` field unchanged. ## Related Observation from code review of the Prettier integration + JS formatting options panel feature wave; UX call rather than a bug.

spikerj commented

2026-05-07 14:09:41 +00:00

Implemented — went with Option 1

Removed the endOfLine field from the visual JS formatting options panel. The store + PrettierLearnerOptions type are intentionally untouched, so an advanced-sandbox .prettierrc editor (or a future copy-to-clipboard / save-as-file affordance) can still set the value — it just doesn't show up in the popover where it gave learners no perceivable feedback.

Changes

libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.html

Deleted the Line endings <label> block (the <select> with endOfLineOptions).
Replaced it with an inline comment that explains why the field was removed, references this ticket (spikersoft-issues#79), and notes the option still lives in the store for advanced consumers — so a future contributor doesn't "helpfully" re-add the select without realizing it was a deliberate UX call.

libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.ts

Removed endOfLineOptions (the ["lf", "crlf", "auto"] const tuple).
Removed the setEndOfLine() setter (only ever called from the now-deleted <select>).
Left a one-line comment in place of endOfLineOptions referencing the ticket so the absence is intentional, not an oversight.

Untouched (by design)

libraries/tools/src/components/js-formatting-options/prettier-config.store.ts — store still patches/normalizes endOfLine.
PrettierLearnerOptions type — still exposes endOfLine: "lf" | "crlf" | "auto".
PRETTIER_DEFAULTS.endOfLine — still "lf".
Reset flow — still resets endOfLine to default.

Verification

nx build tools — clean.
nx test tools — 487 passed / 2 skipped (489 total) across 39 spec files. No spec referenced endOfLine or setEndOfLine, so nothing needed updating.
ESLint / Stylelint / Angular template lint — no errors.

Reversibility

If a copy-to-clipboard / save-as-file path ships later and the demand returns, restoring the visual control is mechanical: re-add the endOfLineOptions const + setEndOfLine() setter (~3 lines) and the <label> block in the same slot the comment now occupies.

## Implemented — went with Option 1 Removed the `endOfLine` field from the visual JS formatting options panel. The store + `PrettierLearnerOptions` type are intentionally untouched, so an advanced-sandbox `.prettierrc` editor (or a future copy-to-clipboard / save-as-file affordance) can still set the value — it just doesn't show up in the popover where it gave learners no perceivable feedback. ### Changes **`libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.html`** - Deleted the `Line endings` `<label>` block (the `<select>` with `endOfLineOptions`). - Replaced it with an inline comment that explains why the field was removed, references this ticket (`spikersoft-issues#79`), and notes the option still lives in the store for advanced consumers — so a future contributor doesn't "helpfully" re-add the select without realizing it was a deliberate UX call. **`libraries/tools/src/components/js-formatting-options/js-formatting-options-panel.component.ts`** - Removed `endOfLineOptions` (the `["lf", "crlf", "auto"]` const tuple). - Removed the `setEndOfLine()` setter (only ever called from the now-deleted `<select>`). - Left a one-line comment in place of `endOfLineOptions` referencing the ticket so the absence is intentional, not an oversight. ### Untouched (by design) - `libraries/tools/src/components/js-formatting-options/prettier-config.store.ts` — store still patches/normalizes `endOfLine`. - `PrettierLearnerOptions` type — still exposes `endOfLine: "lf" | "crlf" | "auto"`. - `PRETTIER_DEFAULTS.endOfLine` — still `"lf"`. - Reset flow — still resets `endOfLine` to default. ### Verification - `nx build tools` — clean. - `nx test tools` — **487 passed / 2 skipped (489 total)** across 39 spec files. No spec referenced `endOfLine` or `setEndOfLine`, so nothing needed updating. - ESLint / Stylelint / Angular template lint — no errors. ### Reversibility If a copy-to-clipboard / save-as-file path ships later and the demand returns, restoring the visual control is mechanical: re-add the `endOfLineOptions` const + `setEndOfLine()` setter (~3 lines) and the `<label>` block in the same slot the comment now occupies.

spikerj closed this issue

2026-05-07 14:09:45 +00:00

spikerj referenced this issue

2026-06-27 19:05:08 +00:00

Language playground UX enhancements: unified action buttons + results in right pane (no-scroll layout) #265

spikerj referenced this issue

2026-07-14 06:30:36 +00:00

[Bug][Infra] InfluxDB rejecting a client every ~10s ("authorization not found") — stale/missing token on a poller #483

spikerj referenced this issue

2026-07-22 02:58:16 +00:00

[Bug][Infra] InfluxDB rejecting a client every ~10s ("authorization not found") — stale/missing token on a poller #483

spikerj referenced this issue