0fcfdd27cdb7d5ab70c50967df7c5065a85fe28c
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Lucas WintherandClaude Opus 5
|
0fcfdd27cd |
fix(fx): the rate service moved, and a browser cannot follow its redirect
"Fetch rates now" failed on the deployed site with nothing but a CORS error. api.frankfurter.app now answers every request with a 301 to api.frankfurter.dev/v1, and a redirect response must itself carry Access-Control-Allow-Origin for a browser to follow it cross-origin. That 301 carries no CORS headers at all, so the request died before the redirect could be taken. Measured rather than guessed, with an Origin header set: api.frankfurter.app -> 301, no access-control-* headers api.frankfurter.dev -> 200, access-control-allow-origin: * The response shape is unchanged, so parseFxResponse needed no edit. Nothing was wrong at build time, which is why this went unnoticed: a server-side fetch follows the 301 freely, so the baked rates were always correct. Only the browser path was broken. Two changes, because a new default alone fixes only some datasets: - DEFAULT_FX_API_URL points at .dev/v1, with a test that fails if the redirecting host ever comes back. - A 3 -> 4 migration drops settings.fxApiUrl when it holds exactly the dead default, which is the case for anyone who edited that field. It is DROPPED rather than rewritten, so the dataset follows whatever the current default is and the next move of the service needs no second migration for the same user; a URL the owner chose is left strictly alone. No stored figure changes, so it cannot alter a number in the budget. Verified by clicking the button in a real browser: "Updated 2 rate(s)", USD 6.456195 and EUR 7.474959 both stored with source "api" — and the USD figure differs from the baked constant, so it is a genuine live fetch. Two migration tests asserted the chain ends at 3; they now assert SCHEMA_VERSION, since what they mean is "all the way through". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Lucas WintherandClaude Opus 5
|
cdece63c68 |
feat: user-defined currencies, and amounts that carry their own currency
Two requests. The second is small; the first changed the money layer.
TYPING THE CURRENCY. The purchase total field now reads "30$" as thirty
dollars, "€25,50" as EUR 25.50, "250 kr" as DKK, "1.234,56 usd" as USD
1234.56, and sets the currency selector from what was typed. Entry speed is a
stated product feature and a second control per amount works against it.
The field is type="text", not type="number": a number input silently discards
anything non-numeric, so "30$" would never reach the parser. It keeps its own
text so a half-typed "30." stays as typed and only commits when it parses.
Separator handling is where parseMoneyInput earns its 26 tests. With both "."
and "," present the LAST is the decimal point, which covers "1.234,56" and
"1,234.56" without knowing a locale. With one, it groups thousands if exactly
three digits follow and is a decimal point otherwise — so "1,500" is fifteen
hundred and "1,5" is one and a half. Spaces group thousands only in
three-digit groups, because "30 40" is two amounts typed by mistake and
committing it as 3040 would be worse than rejecting it. An unrecognised
currency returns null rather than falling back: reading "30 GBP" as 30 DKK
would book money at the wrong currency.
USER-DEFINED CURRENCIES. `Currency` was a closed union and decimal places were
a module constant, so "add a currency" was a code change. Both now live in the
dataset: `Dataset.currencies` is the authority on which codes are valid, what
they are called, their symbol, and how many decimals they round to. Settings
grows a table to add, edit and remove them.
That forced the money layer open. `roundMoney` takes a DIGIT COUNT, not a
currency code, and every one of its ~29 call sites resolves digits from the
dataset via `digitsFor`. Making digits a required number rather than an
optional one with a default of 2 is the whole safety argument: every site
became a compile error the type checker enumerated for me, where a default
would have left each one silently correct for DKK/USD/EUR and silently wrong
for the first zero-decimal currency the owner adds.
Because every existing currency uses two decimals, a broken version of this
refactor would still pass all 356 previous tests. src/domain/currencyDigits.test.ts
is the oracle that cannot lie: a JPY-style zero-decimal currency driven through
roundMoney, both FX directions, both split modes, finance-plan division, the
fold, and the month view, asserting no figure has a fractional yen in it.
Guards that come with it, all tested:
- Codes are identity — they key the FX table and every stored Money — so they
are normalised (" jpy " -> "JPY") and cannot be edited, only added/removed.
- A currency in use cannot be removed, and the refusal names what refers to
it. The same reasoning as posts being archived rather than deleted: stored
Money carries the code, and dangling references would make the import
validator refuse the owner's own exported file. Removing an unused one takes
its exchange rate with it, leaving no orphan row.
- The import validator now checks the currency table itself — codes, duplicate
codes, integer decimals 0-4 — and validates every Money against it. That
boundary check replaces the compile-time safety the closed union provided.
- parseFxResponse takes the accepted codes instead of a global constant, so a
rate service returning dozens cannot put unreachable rows in the table.
Migration v2 -> v3 seeds the currency table. Behaviour-preserving by
construction: every currency that existed had two decimal places and the
seeded table records two, so not one stored amount can round differently than
it did before. An existing `currencies` field is kept rather than overwritten,
since a hand-edited file could already carry currencies the owner added.
Verified in the browser, not just in tests: JPY added through the real Settings
form with 0 decimals, and the five inputs above typed into the real purchase
field, each setting the right currency.
Two obsolete test helpers went away. plans.test.ts and actions.test.ts used to
monkey-patch the CURRENCY_DIGITS constant to prove the table was consulted;
digits are an argument now, so those tests just ask for zero decimals.
types.test.ts no longer asserts "the supported currencies are exactly DKK,
USD, EUR" — that stopped being a property of the code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Lucas WintherandClaude Opus 5
|
b4e1933761 |
feat: bake FX rates in at build time so a fresh install can convert
TODO section 2, designed and approved, now built. A brand-new dataset arrives with DKK/USD/EUR rates instead of erroring on the first EUR purchase. build.ts fetches at build time and embeds the result via `define`. A network failure does NOT fail the build — it bakes committed constants instead, and an incomplete response is treated as a failure too, since one unconvertible currency is the problem this solves. Fetched rates carry source "api" and the BUILD date, which is why parseFxResponse now takes an explicit updatedAt; the constants carry source "manual" and their own date, so Settings never claims a hardcoded number came from a rate service. SKIP_FX_FETCH=1 and FX_API_URL are there for offline, CI and reproducible builds. They seed a NEW dataset and nothing else. They are NOT a fallback for a missing rate: clearing a rate removes its row so MissingRateError surfaces, rather than silently converting money at a number the user never chose. A test asserts a cleared rate still throws, and loading an existing dataset never touches its rates. Domain purity forced the shape. createSeedDataset takes the rates as an argument (and copies the rows, so shared constants cannot be edited out from under the caller); the env read lives in the new src/store/bakedRates.ts behind the try/catch accessor, because an unset BUN_PUBLIC_* leaves a bare process.env in the browser bundle; and createSnapshotStore takes seed rates as a parameter so it stays free of the ambient environment, with src/store/index.ts wiring it. Verified all three build paths: live fetch bakes api-sourced rates with today's date, an unreachable endpoint and SKIP_FX_FETCH both bake manual constants and still build, and the payload is present in the bundle in each case. Verified at runtime that a fresh install converts EUR 100 -> 747.50 DKK and USD 100 -> 644.95 DKK with the variable both set and unset. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Lucas WintherandClaude Opus 5
|
31f030fdea |
feat(ui): add settings for currency, rates, posts, and data
Rate fetching is optional and fails soft: any network or parse error leaves cached rates untouched and shows a message, never throwing into render. A cleared or non-positive FX rate input now calls the new removeFxRate action instead of storing 0, since toBase() silently converts a stored 0 to a 0-value conversion while an absent row correctly throws MissingRateError. Posts are archived, never deleted. Import downloads a backup of the current data before replacing it and requires confirmation showing before/after counts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |