Config & constants

Shared constants and TypeScript types that configure behaviour across apps live in config/constants (@config/constants). Treat this package as the single source of truth for those values—do not copy the same literals into apps/* or core/*.

What belongs here

• App-wide configuration — Locale lists, feature flags, allowed DATA_SOURCE values, and similar shared settings.
• Stable literals and enums — Values that multiple packages must agree on without importing each other’s internals.

API request and response shapes and runtime validation belong in @core/contracts (Zod). See Maintain contracts so you keep boundaries clear: constants describe which options exist; contracts describe what crosses the BFF–storefront wire.

Add constants

1. Create — Add config/constants/src/<domain>.ts and export types and values (e.g. i18n.ts, data-source/index.ts). File names are illustrative—follow existing domains in the repo.

2. Re-export — Wire public exports through config/constants/src/index.ts so consumers depend on @config/constants, not deep file paths.

3. Typing — Prefer literal unions and as const over loose string; avoid any.

Consume

Import @config/constants in apps and packages. Do not duplicate the same constant in multiple places; extend the package instead.

Common touchpoints

• Locales — i18n.ts works together with core/i18n JSON and the BFF. See Translations.

• Data source — Allowed providers and related constants typically live next to Data sources wiring (e.g. data-source/index.ts).

New package under config/

To add another config/* workspace package (not only files inside config/constants), follow Other workspaces and mirror an existing config/ package’s package.json and tooling.

Related

• Maintain contracts — @core/contracts, Zod, BFF–storefront types
• Translations — Locale JSON and BFF i18n
• Data sources — BFF factory and integrations
• Other workspaces — Adding config/* packages
• General workflow rules

Back to Building blocks · Back to How to work with SHOPin