panates / rman / 36712016498

95%

push

github

feat: export mergeConfig, for a config assembled in JavaScript

`@panates/rman-preset` composes one config from a platform-neutral half and a
Node one, and the obvious ways to do that in JavaScript both get rman's own
layering wrong - measured:

- A plain spread is shallow. Two halves both declaring `changelog` keep only the
  later one's, wholesale and silently.
- A general-purpose deep merge fixes that and breaks the other half:
  `@jsopen/objects`' `merge({deep: true})` turns `commands: ['a','b']` merged
  with `['c']` into `['c']`, while rman *appends* those. `commands`, `plugins`,
  `platforms` and `publishTargets` are `ALWAYS_APPEND` keys precisely because
  naming a command of your own never means "and drop the ones my base brought",
  so a generic merge would lose a preset's commands the day either half declared
  one the other already had.

`mergeConfig` is the function that knows those rules, and nothing outside rman
could reach it.

**`extends` remains the better answer where it fits**, and the export's own doc
says so: a config module can carry `extends: ['./other.js']` and let rman do the
merging, which costs no API surface and keeps each key's origin pointing at the
file that holds it. Measured to work for a JS module extending a JS module,
nested inside a config that is itself an `extends` target - which is what the
preset now does. This export is for the case where one module has to hand back a
single finished object.

No new types: the signature is `(target, source, origin?)` over
`Record<string, any>`, mutating and returning `target`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2988 of 3274 branches covered (91.26%)

Branch coverage included in aggregate %.

26 of 26 new or added lines in 1 file covered. (100.0%)

18097 of 19076 relevant lines covered (94.87%)

205.54 hits per line