Library

React Components / v9 (@fluentui/react-components)

Describe the feature that you would like added

I want Fluent's ESM output (CJS can go either way I think) to include the .js extension for all relative JS imports. For example,

// Source Typescript
import { feature } from './file';

// Output ESM Javascript
import { feature } from './file.js';

This update will better allow Fluent's ESM output to be loaded directly in the browser (import maps will still be required to resolve bare package imports but that's no problem).

Ideally we should do this without changing source code and leverage something like SWC's @swc/plugin-transform-imports (which transforms exports in addition to imports despite the name).

Have you discussed this feature with our team

@Hotell @chrisdholt

Additional context

Currently the ESM output from Fluent is "extensionless" which prevents the ESM output from working correctly in a browser.

// Example output of current output
import { FluentProvider } from '@fluentui/react-components'; // bare module
export { something } from './somewhere'; // bare JS file

// Example of what this needs to be for native ESM support
import { FluentProvider { from '@fluentui/react-components;
export { something } from './somewhere.js';

In this example there is a "bare module" import where code is imported from a package name (that lacks a .js extension) and a "bare JS file" import. The latter is typically used within a package to import other JS files using relative paths.

We can address "bare modules" with importmaps, allowing import $whatever from 'some-module-without-an-extension' to resolve correctly but importmaps cannot, effectively^†, handle the internal bare JS imports. To handle the bare JS imports we must update the output to include the .js extension.

^† I say effectively because it is possible to generate an importmap for all the base JS imports within a package but such an importmap would be quite large and then require end users to correctly merge it with any other importmaps they are using. Technically possible but not a good solution :)

Related issues

• [Feature]: support native ESM modules from CDN #23508

Validations

• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Priority

Normal