angular cli bundles umd version instead of esm

[atsjo]

Warning from Angular-cli: Warning: ... depends on 'fast-equals'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

I don't have this problem with any other libs exporting multiple module formats, and the problem here is probably that webpack prioritizes the "browser" export instead of "module" in package.json when both are available.

This can be fixed in multiple ways I guess, the esbuild docs (https://esbuild.github.io/api/#main-fields) mentions the below format when mixing browser and module exports...

{ "main": "./node-cjs.js", "module": "./node-esm.js", "browser": { "./node-cjs.js": "./browser-cjs.js", "./node-esm.js": "./browser-esm.js" } }

But maybe using the exports field is a better solution...

[planttheidea]

I can certainly look into this. While the recommendation and documentation you point to is esbuild-specific (which does not apply to this library, as it uses rollup for builds), there is something that is similar available in later versions of npm ... the exports field. This is supported in node starting with version 13.2, and TypeScript starting with version 4.5, so it should help peeps on latest build dependencies. I'll need to do some research, though, to determine precedence over the older main / module / browser setup, and how that looks to determine if it is a breaking change (dropping older infrastructure support always is).

For your immediate needs, though ... it sounds like you are using webpack for your builds? If so, webpack offers the ability to alias dependencies which may help. There are also more broad resolution order options as well, and if you've explicitly set the target (example: target: 'web') then the browser field is ignored (per that documentation). This would also explain why you are seeing the above message, because browser is actually a UMD export; only main is using a CJS export.

Hope this helps, and in the meantime I'll look into the newer export delegation options.

[atsjo]

Angular-cli abstracts away webpack, and give no easy options for customizing the webpack config used internally. It still works with this warning though, it just signals that it might not be able to tree-shake the module properly. I ended up trying dequals, which worked fine.

[planttheidea]

I know its been a while, but life got crazy. However, I have just published 5.0.0-beta.0 which leverages the exports field for better asset resolution. If you want to test by doing npm i fast-equals@next / yarn add fast-equals@next I'd appreciate it.

[ranma42]

It looks like the .d.ts files in the package reference the sources (also shipped within the package). This might cause build errors depending on the TS build target:

Error: node_modules/fast-equals/src/utils.ts:91:10 - error TS2550: Property 'hasOwn' does not exist on type 'ObjectConstructor'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2022' or later.

91   Object.hasOwn ||
            ~~~~~~

Apart from this, upgrading to the current next (beta.1) did not require any change to the app. Thank you! :)

[planttheidea]

Thanks @ranma42 ! I'll refactor to eliminate imports to anything other than the internal types file, which should resolve the issue above. Appreciate the feedback!

EDIT: 5.0.0-beta.2 released with updates to type imports.

[ranma42]

Confirmed, beta.2 makes the build go just fine even without any change to tsconfig. Thank you for the quick fix!

[atsjo]

tested with beta 6 and angular, and cli/build doesn't report any warnings now:-)

[planttheidea]

Great! If I get some time this weekend I'll take it out of beta, cuz I think it's ready. Thanks for the feedback!

[planttheidea]

5.0.0 has been published with better support for different build environments. If you have any more issues, let me know!