Skip to content

deps: bump @hochfrequenz/efoli to ^2.0.0 - #973

Draft
hf-kklein wants to merge 1 commit into
mainfrom
bump-efoli-2
Draft

deps: bump @hochfrequenz/efoli to ^2.0.0#973
hf-kklein wants to merge 1 commit into
mainfrom
bump-efoli-2

Conversation

@hf-kklein

Copy link
Copy Markdown
Contributor

Moves from ^0.0.9 (which resolves to exactly 0.0.9) to ^2.0.0, picking up FV2704 and the validation changes in efoli.ts v2.0.0.

No code change needed — both new throwing paths are already guarded

efoli 2.0.0 throws where it previously returned a wrong answer. I checked each call site against that:

  • getFormatVersionLabel (format-version-select.component.ts:90) calls getEdifactFormatVersionLabel only after Object.values(EdifactFormatVersion).includes(formatVersion), falling back to the raw string otherwise. It can never pass a non-member, which is the only input that now throws. (Without that guard this would have been the risky one: 0.0.9 returned undefined there, and a ?? fallback would now throw instead.)
  • resolveFormatVersion (server/service/validation.ts:76) parses an ISO date and rejects impossible ones itself — toCalendarDate does the same UTC round-trip efoli 2.0.0 now performs internally, raising ValidationError before efoli sees the value. ISO_DATE_PATTERN also pins the year to four digits, inside efoli's new 1–9999 bound.

So the externally-visible error contract is unchanged: malformed dates still surface as ValidationError, not as an efoli Error.

KNOWN_FORMAT_VERSIONS is built from Object.values(EdifactFormatVersion), so FV2704 becomes accepted input automatically with no edit.

Gates were not run locally — please let CI be the judge

This repo requires node >=23.11.0 (.nvmrc: v23.11); only node 18 is available in my environment and no version manager is installed, so I did not install anything system-wide.

  • test, lint, format:check and the builds were not run by me.
  • The lockfile was edited, not regenerated: only the dependency range, and the package entry's version/resolved/integrity. Regenerating under npm 9 would have introduced unrelated churn. Diff is 5 lines.
  • The integrity hash was read from registry.npmjs.org for 2.0.0, not typed by hand, and the lockfile was re-parsed as JSON afterwards.

If CI is green this is safe to merge; if it is red, suspect the lockfile first and regenerate it on node 23.

🤖 Generated with Claude Code

Picks up FV2704 and the validation changes in efoli.ts v2.0.0.

Neither of v2.0.0's new throwing paths is reachable from this codebase, so
no code change is needed:

- getFormatVersionLabel (format-version-select.component.ts) only calls
  getEdifactFormatVersionLabel after checking membership in
  Object.values(EdifactFormatVersion), so it never passes a non-member.
- resolveFormatVersion (server/service/validation.ts) parses an ISO date and
  already rejects impossible dates itself, via the same UTC round-trip efoli
  2.0.0 now performs internally, raising ValidationError before efoli sees
  the value. Its ISO_DATE_PATTERN also constrains the year to four digits,
  inside efoli's new 1-9999 bound.

Gates were not run locally: this repo requires node >=23.11.0 and only node
18 is available here. The lockfile was edited to the efoli entries alone
rather than regenerated under the wrong npm, and the integrity hash was
taken from the registry. CI runs on the right node.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@hf-kklein hf-kklein changed the title Bump @hochfrequenz/efoli to ^2.0.0 deps: bump @hochfrequenz/efoli to ^2.0.0 Sep 9, 2026
@github-actions github-actions Bot added the dependencies Pull requests that update a dependency file label Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant