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.