Jest starts throwing Jest encountered an unexpected token in Angular

[timonmasberg]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/angular-ivy

SDK Version

7.77.0

Framework Version

Angular 16.2

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

1. Updating @sentry/angular-ivy to 7.77.0 (from 7.57.0)
2. Running tests with jests where something is imported from @sentry/angular-ivy

You can use this branch to reproduce it.
You can see the error here in the pipeline.

Expected Result

The tests should work without any special modification to the Jest configuration (such as enabling experimental ESM support).

Actual Result

Running the jest test no throw an error:

...
/node_modules/@sentry/angular-ivy/sentry-angular-ivy.d.ts:5
    export * from './index';
    ^^^^^^
 SyntaxError: Unexpected token 'export'
...

Maybe this change introduced this behavior. Or perhaps I am missing something I could not find in the changes. Any idea why this might fail?

[Lms24]

They @timonmasberg thanks for writing in! I think your suspicion is correct, this screams #9412. Which is problematic because we kinda need this hack for proper Angular 17 support. I'll revisit this next week and try to come up with something else. Thanks for letting us know!

[Lms24]

@timonmasberg

thank you for the reproduction example, I was able to reproduce this.

I looked into this a bit, trying to establish if there's some problem in your config in particular that's causing this or if it's a more general/widespread issue. What I don't yet understand about the error you're getting is that you're using the jest angular preset which afaik shouldn't have any problems with ESM files. It's also super weird that this error is thrown in a d.ts file which by nature can only be ESM. So I'm wondering why it'd complain about the exports keyword there.

If I locally add back the main entry point in the @sentry/angular-ivy and point it to the fesm2015 ESM bundle, I get the same error. Only if I point it to the CJS/UMD bundles directory, things work again. Which confirms that the appearance of the error is caused by #9412.

Something might be wrong in the Nx resolver that tries to resolve the import from @sentry/angular-ivy. You're using this implicitly by extending your jest config from Nx' config. I'm not sure though how to change this best or which other resolver might work here. Maybe it's worth checking in with the Nx folks.

However, given that the resolver resolves successfully to the esm, it might also be caused by a weird transformer setting. Again super confusing because I'd expect the Angular preset should to handle TS and ESM pretty well...

One (admittedly not great) workaround is to kind of take Sentry out of the equation when testing, by straight up mocking the @sentry/angular-ivy package:

jest.mock('@sentry/angular-ivy', () => ({ setUser: () => {} }));
import * as SentryAngularIvy from '@sentry/angular-ivy';
const sentrySetUser = jest.spyOn(SentryAngularIvy, 'setUser');

If I add the jest.mock call, the tests pass for me again. The import will then import the mocked version of the Sentry module which bypasses actually importing the Sentry package.

Let me know if this works for you or if you have other ideas.

As for reverting #9412, I'd like to avoid this at the moment, given that we need to also support Angular 17 (as of today lol). I'm also curious if other users are affected by similar problems or how well our Angular 17 compatiblity hack holds up once more people upgrade to the version.

PS/offtopic: Cool project you're building here! I used to work at Red Cross in Austria as a volunteering EMT before moving to Vienna ;)

[timonmasberg]

I looked into this a bit, trying to establish if there's some problem in your config in particular that's causing this or if it's a more general/widespread issue. What I don't yet understand about the error you're getting is that you're using the jest angular preset which afaik shouldn't have any problems with ESM files. It's also super weird that this error is thrown in a d.ts file which by nature can only be ESM. So I'm wondering why it'd complain about the exports keyword there.

This is what I thought, we also have other es modules we mock in tests that work seamlessly.

You're using this implicitly by extending your jest config from Nx' config. I'm not sure though how to change this best or which other resolver might work here. Maybe it's worth checking in with the Nx folks.

Yes, NX is very opinionated, which is good and easy until it isn't anymore ;) The resolver seems to use the exports property from the package.json when using the Jest default resolver and also as a fallback, which is not declared for the package. I don't know if adding them for each entry point might help to resolve the correct module.

Let me know if this works for you or if you have other ideas.

This works and is acceptable until we need a real implementation from the package. Thanks!

---

All in all, it seems to be a problem on our end, that is why I am fine with closing this issue if you think the previously mentioned stuff won’t help.

Thanks again for the assist.

[joergbaier]

In my case I was getting Cannot find module '@sentry/angular-ivy' from '<filename>'

My quick hack was adding this to my jest moduleNameMapper

"@sentry/angular-ivy": "<rootDir>/node_modules/@sentry/angular-ivy/bundles/sentry-angular-ivy.umd.js"

[schmkr]

For what it is worth, we are experiencing the same issue, since v7.77.0 (and as a result, have not yet been able to update).

We are also using Nx and its executor for Jest tests. I already tried updating jest-preset-angular to see if that would resolve the issue, but unfortunately it did not.

The above mentioned workaround with the moduleNameMapper solves it for us too, although I had to provide an absolute path from the workspace root.

[Lms24]

Hi, thanks for letting us know and I apologize for the inconvenience. To be clear, I agree that this isn't ideal and we should, if possible at all, fix it. Unfortunately, I'm a) very limited on time as I'm booked with multiple p0 tasks and b) running out of ideas how to restore Jest<>Nx support while maintaining Angular 17 support (which is a must). If anyone has an idea, feel free to let us know (PRs are also welcome ❤️).

Some context for NG17 support:

• require() of ES Module @angular/core/fesm2022/core.mjs not supported #9376
• fix(angular-ivy): Adjust package entry points to support Angular 17 with SSR config #9412
• application builder: require() of ES Module @angular/core/fesm2022/core.mjs not supported angular/angular-cli#26135

One thing we will do in v8 of the SDKs is bump the minimum Angular version to a more recent APF standard. My current thinking is APF15 but this might still change. I assume that Nx will be compatible with this format, so this should also resolve the issue.

[Lms24]

Hi folks, we'll address this issue in our new major which tentatively is expected to land in January. Our current plan is to

1. merge the @sentry/angular and @sentry/angular-ivy package back into @sentry/angular
2. increase the minimum Angular version support number so that we can fully support the package format that's required for Angular 17. bumping this min version should hopefully eliminate this issue.

For anyone interested, please follow this issue: #9830

[Lms24]

Hey all, I have an update for anyone following this issue: @s1gr1d has been hard at work improving our Angular Support for more recent Angular versions and I just tested the changes in #11091 with the repro from @timonmasberg. I can now run npm run test:all in the root without any test fails.

The changes in #11091 are expected to be released with the next alpha version of v8, presumably sometime this or next week. We'd appreciate it if someone is brave enough to update to an alpha build and lets us know if it works as expected.
Otherwise, once we go stable with v8, this issue should be resolved :)

[s1gr1d]

I will close the issue, as this will be included in 8.0.0-alpha.5.

Fell free to tag me if this issue persists on your end or if you think this should be reopened.

[orl99]

When is 8.0.0-alpha.5 going to be a stable version?

[Lms24]

We'll release a beta in the next days, meaning no more breaking API changes! 🎉 We're then looking at a testing and feedback period for beta and RC builds where we'll iron out any reported regressions and apply more optimizations. So any feedback with the beta builds would be highly appreciated 🙏

Can't give you an excat ETA for a final stable 8.0.0 version but a tentative guess would be 4 weeks from now :)