feat(mrt-utilities): add development data-store with dist export

[bendvc]

PR Details

• add a development pseudo data-store implementation for @salesforce/mrt-utilities/data-store that reads defaults from SFNEXT_DATA_STORE_DEFAULTS and keeps strict missing-key parity with production (DataStoreNotFoundError)
• keep the public interface stable while reorganizing data-store into a symmetric layout (index.ts re-exporting production.ts, plus development.ts)
• update ./data-store conditional exports to resolve development to built dist files, add dev behavior tests, and document local development usage in package/docs guides
• add a changeset for @salesforce/mrt-utilities and update prepack strip behavior to remove only development exports that reference ./src

Test plan

• pnpm --filter @salesforce/mrt-utilities run test:agent
• pnpm --filter @salesforce/mrt-utilities run lint:agent
• pnpm --filter @salesforce/mrt-utilities run typecheck:agent

[kevinxh]

If I understand correctly, this line:

"development": "./src/data-store/index.ts",

is intended for internal monorepo development currently — but it also has implications for downstream consumers, right? Why not lean into that and optimize the development condition for downstream consumers instead?

Non-blocking suggestion: could we conditionally rewrite the exports during the mrt-utilities build so that consumers like Storefront Next can rely on Vite's built-in development condition rather than having to set NODE_OPTIONS=--conditions=dev-data-store?

Concretely, during build we'd replace:

"development": "./src/data-store/index.ts",

with:

"development": {
  "import": {
    "types": "./dist/esm/data-store/development.d.ts",
    "default": "./dist/esm/data-store/development.js"
  },
  "require": {
    "types": "./dist/cjs/data-store/development.d.ts",
    "default": "./dist/cjs/data-store/development.js"
  }
}

Happy to discuss if there's context I'm missing.

[bendvc]

That is a subtlety that I touch upon in our conversation earlier. Currently we have a pattern, condition=development means we point at the source. I didn't want to break that convention by pointing at a different built module.

I actually had it this way but I didn't want to semantically overload the word "development" in this case.

Long story short, I don't want to rock the boat too much. Since vite probably uses that development condition I don't want it to mean one thing for one file and another for a different one.

[bendvc]

Lets broach this subject with @clavery when he is back to work

[kevinxh]

don't forget to remove this file before merging?