This is a tradeoff support for ES modules in the output of frontend packages.
@itwin/imodels-client-management package has many exported modules that are labeled as private, but they can still be imported using full path specifier by the end users. I keep commonjs output the same as before to preserve these import paths, but place ES output to lib/esm. If you consume this package in your ES module using bare specifier, e.g.
import {...} from "@itwin/imodels-client-management"
then only ES modules would be imported. But if you begin mixing imports by full path in the same project, then it would drag in commonjs version too. I think intellisense of vscode would suggest to add import paths to cjs version if object/function/class used is not reexported from the main package barrel file.
To solve this issue "exports" of package.json should be defined, which effectively restricts the public surface. But that would cause breaking changes both for end users and other packages in this monorepo. I'd suggest to plan these changes in the next major version.
@itwin/imodels-access-frontend has only 2 files, everything is reexported from the barrel. It depends on @itwin/imodels-client-management, but there are no full path imports from it. Therefore consuming @itwin/imodels-access-frontend as ESM would yield @itwin/imodels-access-frontend as ESM too with proper tree shaking etc.
This is a tradeoff support for ES modules in the output of frontend packages. @itwin/imodels-client-management package has many exported modules that are labeled as private, but they can still be imported using full path specifier by the end users. I keep commonjs output the same as before to preserve these import paths, but place ES output to lib/esm. If you consume this package in your ES module using bare specifier, e.g.
import {...} from "@itwin/imodels-client-management"
then only ES modules would be imported. But if you begin mixing imports by full path in the same project, then it would drag in commonjs version too. I think intellisense of vscode would suggest to add import paths to cjs version if object/function/class used is not reexported from the main package barrel file.
To solve this issue "exports" of package.json should be defined, which effectively restricts the public surface. But that would cause breaking changes both for end users and other packages in this monorepo. I'd suggest to plan these changes in the next major version.
@itwin/imodels-access-frontend has only 2 files, everything is reexported from the barrel. It depends on @itwin/imodels-client-management, but there are no full path imports from it. Therefore consuming @itwin/imodels-access-frontend as ESM would yield @itwin/imodels-access-frontend as ESM too with proper tree shaking etc.