Release Notes

Version 1.1.0

📅 Release Date

August 8, 2026

📖 Overview

One addition. An application can now say how hard it tries when it posts to a service it does not control, through the same configure/resolve path every other setting travels.

Before this, that policy lived wherever the fetch was written — a timeout literal in a service class, a retry loop inlined at the call site — which makes a timeout change a code change and a redeploy. delivery is the fourth thing this package settles, alongside logging and security.

🚀 Features

• DeliverySettings: a settings module describing how an outbound request behaves.

  export interface DeliverySettings {
    timeoutMs: number
    retries: number
    retryBackoffMs: number
    userAgent: string
  }
  

The entry point now publishes 43 names, up from 42. The exports map is unchanged — . and ./package.json, nothing deeper — so this arrives through the same single import as everything else.

🔧 Enhancements

• The defaults are deliberately unheroic:

  delivery: {
    timeoutMs: 10000,
    retries: 2,
    retryBackoffMs: 250,
    userAgent: 'app'
  }
  

  Ten seconds an attempt, two retries, and a backoff doubling from a quarter of a second. Worst case is a little over thirty seconds of wall clock, which is the number to have in mind: backoff is spent inside the request that triggered the delivery, so the caller waits through it. timeoutMs is the one to tighten when callers are less patient.

• userAgent is 'app' for the same reason logging.service is — a library default has no business naming somebody's application, and a deliberately generic placeholder means an un-overridden deployment reads as unconfigured to whoever is looking at the receiving service's access log. Override it, or that log says nothing about who is calling.

• It belongs in the kernel rather than an adapter. It came up from an application carrying it in a vendored copy of the pre-extraction kernel, and the answer is the test everything else here passes: it names no vendor, no runtime, and no HTTP framework. A timeout, a retry count, a backoff, and an identity to send are the same four decisions on any runtime that can make an outbound request. It is also the one settings module with no platform resource behind it — nothing has to exist for it to be meaningful, only a fetch.

• Nothing in this package reads it. That is deliberate rather than unfinished. This package publishes the shape and the default; the application that actually posts is where the policy gets applied. Adding a delivery client here would mean shipping an HTTP client from a package whose whole premise is that it ships none.

⚠️ Breaking Changes

• SystemConfiguration gains a required member. Anything constructing that surface by hand rather than spreading systemDefaults will stop type-checking until it supplies delivery. The spread form is what the boilerplate does and what every service forked from it does, so in practice this lands as a minor. The compile error is confined to hand-built surfaces — most often a test fixture that assembles a literal instead of spreading — and it is the good kind: it names the missing member at the construction site rather than surfacing later as a resolve('delivery') that throws ConfigurationError.

Runtime behaviour is unchanged. No existing field moved, no default was re-tuned, and nothing new is read at startup.

🧪 Tests

npm run lint, npm run test:run (85 specs, nine suites), and npm run build all clean. The spec count is unchanged from 1.0.0, which is the honest outcome for a release that adds a type and an object literal: there is no branch here to exercise. The declarations build is the check that carries weight — lib/index.d.ts exports 43 names, and the required-member addition is visible in it.

🚨 Known Issues

• None

📦 Dependencies

• Runtime: none — unchanged
• Toolchain: unchanged

⬆️ Upgrading

npm install @bayudwiyansatria/core@1.1.0

If you spread systemDefaults into configure(), there is nothing to do — you get the defaults above and can override any of the four:

configure(
  { ...systemDefaults, ...platformDefaults },
  {
    delivery: { timeoutMs: 3000, userAgent: 'example-service/1.0.0' }
  }
)

Per-field merge applies as everywhere else, so naming two fields keeps the defaults for retries and retryBackoffMs.

If you build the configuration surface by hand, add delivery to it. Set userAgent in either case.

👥 Contributors

• Bayu Dwiyan Satria

🙏 Acknowledgments

Thanks to all contributors and users whose feedback surfaced the missing setting.

For more information, visit the project's GitHub repository.