application builder: require() of ES Module @angular/core/fesm2022/core.mjs not supported

[zip-fa]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

17.0.0-next.9

Description

Hi. I couldn't start dev server after upgrading from next.9 to rc.1.

This package triggers error:

"@sentry/angular-ivy": "^7.50.0",

Updating to latest version didn't help.

Import which leads to error:

import { createErrorHandler, TraceService } from '@sentry/angular-ivy';

{
      provide: ErrorHandler,
      useValue: createErrorHandler({
        showDialog: false,
        logErrors: !environment.production
      })
    },

Minimal Reproduction

ng serve/nx serve

Exception or Error

with ng serve:

[vite] Error when evaluating SSR module /chunk-WEHZQJTE.mjs: failed to import "@sentry/angular-ivy"
|- Error [ERR_REQUIRE_ESM]: require() of ES Module /node_modules/@angular/core/fesm2022/core.mjs not supported.
Instead change the require of /node_modules/@angular/core/fesm2022/core.mjs to a dynamic import() which is available in all CommonJS modules.
    at /node_modules/@sentry/angular-ivy/bundles/sentry-angular-ivy.umd.js:2:113
    at Object.<anonymous> (/node_modules/@sentry/angular-ivy/bundles/sentry-angular-ivy.umd.js:5:3)

with nx serve:

[vite] Internal server error: require() of ES Module /node_modules/@angular/core/fesm2022/core.mjs not supported.
Instead change the require of /node_modules/@angular/core/fesm2022/core.mjs to a dynamic import() which is available in all CommonJS modules.
      at Module.require (/node_modules/nx/src/adapter/compat.js:34:40)
      at /node_modules/@sentry/angular-ivy/bundles/sentry-angular-ivy.umd.js:2:113
      at Object.<anonymous> (/node_modules/@sentry/angular-ivy/bundles/sentry-angular-ivy.umd.js:5:3)

Your Environment

Angular CLI: 17.0.0-rc.1
Node: 18.18.2
Package Manager: npm 9.8.1
OS: darwin arm64

Angular: 17.0.0-rc.1
... animations, cli, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic
... platform-server, router, service-worker

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.0-rc.1
@angular-devkit/build-angular   17.0.0-rc.1
@angular-devkit/core            17.0.0-rc.1
@angular-devkit/schematics      17.0.0-rc.1
@angular/cdk                    17.0.0-next.6
@angular/material               17.0.0-rc.0
@angular/ssr                    17.0.0-next.9
@schematics/angular             16.2.5
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.0

Anything else relevant?

No response

[alan-agius4]

This appears to be a bug in Angular sentry, @angular/core is an ESM module and has been for a number of major versions and cannot be required. Checking their package.json, they are still on Angular version 12.

Under Webpack this worked because Webpack has it's own module system. However, in version 17 when using the application builder SSR is using ESM modules and thus standard ESM resolution rules apply.

[Lms24]

Hi, Sentry Angular SDK maintainer here 👋

@alan-agius4 thanks for the explanation! Is there any way we can make our package compatible with Angular 17 without dropping Angular 12 support? As far as I understand, Angular's library compatibility philosophy, libraries should be forward-compatible with new Angular versions, correct?

[Lms24]

@alan-agius4 I did some more research and testing and I believe it comes down to our SDK being imported and used on the server side during SSR. This is something our package is not intended to be used in as it relies heavily on browser APIs. Angular+SSR is something we'd need to support in addition to client-side Angular.

As for the current @sentry/angular-ivy package: When excluding the Sentry providers from the app.config.server.ts exported config object, so that they're only used in the client side config (see here), the error message disappears. Not ideal but at least there's a workaround.

Is there a way we can solve this more nicely, ideally with users not being required to change anything? Unfortunately, we cannot just upgrade our Angular package to be compiled with a more recent package version because:

1. We're in a monorepo and releasing a major version update to acommodate the breaking change can only happen when we cut a major release for all our packages. IOW, we're not going to release a major just to break in our Angular SDK.
2. Our Sentry SDK development philosophy requires us to maintain compatibility with old versions as long as reasonable possible (We support NG10 to 16(17) at the moment).

Would love to work together with you and the Angular team to solve this!

[alan-agius4]

Hi @Lms24,

thanks for the explanation! Is there any way we can make our package compatible with Angular 17 without dropping Angular 12 support? As far as I understand, Angular's library compatibility philosophy, libraries should be forward-compatible with new Angular versions, correct?

This is quite an extended range, typically libraries support the version used to compile the library + 2 major versions, although there are cases which this doesn't apply. IE: if a library was built using Angular 12, it will support 12, 13 and 14.

The root problem here is is that the built version of the @sentry/angular-ivy ships UMDs which rely on Angular UMD bundles. This was valid some years ago, but since than Angular packages are ESM only, will this worked before for some because Webpack has it's own module system. With version 17 we are promoting a build pipeline that uses esbuild and vite and produces pure ESM output.

One workaround that you could do is to remove the UMD bundles from the dist package and remove the main field from the package.json.

It's also worth mentioned that Angular versions prior to 14 are no longer supported by the Angular team. For more information please see: https://angular.io/guide/releases#actively-supported-versions

[Lms24]

IE: if a library was built using Angular 12, it will support 12, 13 and 14.

@alan-agius4 Thank's for explaining, I wasn't entirely aware of this but it makes sense. Still quite a challenge for us but I guess we have to figure this out. So just to confirm, if we compile our package now with Angular 15, it will ensure compatiblity with NG15, 16 and 17. Everything beyond 17 would no longer be guaranteed. Correct?

It's also worth mentioned that Angular versions prior to 14 are no longer supported by the Angular team

Yup, I'm aware. As I said, the Sentry SDK guidelines "require" me to support even older versions as long as possible (for example, we currently still support ancient Node 8 🙈). However, with your note about forward compatibility only lasting for 2 majors, we might consider breaking whenever we get to our next major version.

One workaround that you could do is to remove the UMD bundles from the dist package and remove the main field from the package.json.

I'll give this a try. I guess the downside is that we're then no longer APF12-compliant but if that's what it takes to get things working for now, I'll take it.

[alan-agius4]

So just to confirm, if we compile our package now with Angular 15, it will ensure compatiblity with NG15, 16 and 17. Everything beyond 17 would no longer be guaranteed. Correct?

Yes, that is correct.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}