docs: Update Client Requirements template for 3.0 release

[Joshua Smithrud (Josmithr)]

Updates the Client Requirements template with updates for 3.0. This content is embedded in the majority of our library package READMEs.

Note

This won't be merged until we are ready to begin checking in breaking changes for 3.0.

AB#78964

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (35 lines, 1 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[Jason Hartman (jason-ha)]

I wonder if we should call out Jest+require-ESM issue in here.
NodeJS supports require-ESM fully as of 22.12.
Jest want's NodeJS 24.9 or later.

[Craig Macomber (Microsoft) (CraigMacomber)]

We might want to explicitly support require(ESM) (see https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require ) and ensure our ESM modules are compatible with that (in our case that mainly means avoiding top level await, which we currently do not use).

Suggested change

	CommonJs is no longer officially supported as of version 3.0.
	We no longer publish CommonJs modules as of 3.0, however we do support loading our ES Modules from CommonJs using [require(ESM)](https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require) which is supported in NodeJS `>=22.12.0`.

[Craig Macomber (Microsoft) (CraigMacomber)]

Note that the change you made is stricter, which means we could do what you said for now, and then if customers need require(ESM) we could add support for it (as I suggested).

My suggestion would ban top level await in our code, where yours would not.

Thus maybe we want to do with your phrasing for now as that reserves our ability to do top level await, which is useful (like async loading wasm modules)

[Craig Macomber (Microsoft) (CraigMacomber)]

Either way, eventually we want to allow us to use top level await, so if we support require(ESM) in 3.0, we likely want to drop it in 4.0.

[Joshua Smithrud (Josmithr)]

Note that the change you made is stricter, which means we could do what you said for now, and then if customers need require(ESM) we could add support for it (as I suggested).

This was my thinking. I generally erred on the side of under-promising with the expectation that we may end up wanting or needing to actually deliver more.

I'd be fine applying your suggested changes if folks would prefer, but my inclination would be to err on the side of being stricter and coming back to this as needed.

[Jason Hartman (jason-ha)]

We can say not officially supported and then go on to note that conditionally (experimentally?) require-ESM may be used to use FF from CJS. We'll want to add a note about using tsconfig options required. I think those might be:

  "compilerOptions": {
    "module": "Node20", // or NodeNext
    "customConditions": ["module-sync"]
  }

but I need to recheck. I will reply when I confirm.

[Jason Hartman (jason-ha)]

We can say not officially supported and then go on to note that conditionally (experimentally?) require-ESM may be used to use FF from CJS. We'll want to add a note about using tsconfig options required. I think those might be:

  "compilerOptions": {
    "module": "Node20", // or NodeNext
    "customConditions": ["module-sync"]
  }

but I need to recheck. I will reply when I confirm.

[github-actions]

Bundle size comparison

Base commit: 28be1d33e075a0fdb1df77db2adfd0f81140e4ae
Head commit: 21c18ede2f50e9a5f840f9344ff48574bbe9b1d6

Pending — Build - client packages is running. Results will appear here when the build completes.

[Copilot]

Pull request overview

Updates the shared “Client Requirements” Markdown template used by markdown-magic to reflect the intended runtime/tooling support policy for the upcoming 3.0 major version, so downstream package READMEs inherit the updated requirements text.

Changes:

• Refreshes supported runtimes to Node.js 22/24 and modern browsers targeting ES2022.
• Updates supported tooling guidance to TypeScript 6.0 and adds an explicit ES2022+ build-target requirement.
• Tightens module format guidance by making ES Modules required and marking CommonJs as unsupported starting in 3.0.

Suppressed comments (2)

tools/markdown-magic/src/templates/Client-Requirements-Template.md:23

• The TypeScript release-notes links point to typescriptdocs.com, which appears to be a third-party mirror and is inconsistent with other repo docs that link to typescriptlang.org (e.g. common/build/build-common/README.md:40). Using the official release-notes URL reduces link-rot risk.

-   [TypeScript 6.0](https://typescriptdocs.com/release-notes/TypeScript%206.0):
    -   All [`strict`](https://www.typescriptlang.org/tsconfig) options are supported.
    -   Build targets (`lib`, `target`) must specify `ES2022` or later.
    -   [`strictNullChecks`](https://www.typescriptlang.org/tsconfig) is required.
    -   [Configuration options deprecated in 6.0](https://typescriptdocs.com/release-notes/TypeScript%206.0#breaking-changes-and-deprecations-in-typescript-6-0) are not supported.

tools/markdown-magic/src/templates/Client-Requirements-Template.md:39

• This sentence uses "NodeJs" while earlier bullets use "Node.js". Using one spelling consistently avoids confusion in a template that is embedded across many READMEs.

    ES Modules are the required way to consume our client packages (including in NodeJs).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

🔗 Found some broken links! 💔

Run a link check locally to find them. See Checking for Broken Links for more information.

linkcheck output

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-website@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/
[ELIFECYCLE] Command failed with exit code 1.

[github-actions]

Bundle size comparison

Base commit: unresolved
Head commit: 21c18ede2f50e9a5f840f9344ff48574bbe9b1d6

⚠️ Comparison unavailable.

The PR's CI build failed — fix the build and the comment will update once the next run succeeds.