Cannot read properties of undefined (reading 'operators')

hi,
I’ve converted our application from Jest to Vitest and most of the unit tests pass, but there are a number of them that fail, at the same time I’ve updated to the latest version of
@okta/okta-angular”: “^6.4.0”,
@okta/okta-auth-js”: “^7.7.0”,

The tests all use a service that calls OktaAuth and OKTA_AUTH, so my initial thought was to add a provider for the AuthService, but that does not work.

the error message is:
TypeError: Cannot read properties of undefined (reading ‘operators’)
node_modules/@okta/okta-angular/bundles/okta-okta-angular.umd.js:4:240

Looking at that file the only reference I can find is to rxjs/operators.

Thanks inadvance

Hi there Duncan - Welcome to the community!

Let’s see if we can figure this out. I haven’t tried using Vitest yet, so this will be new to me. Just to double-check, are you using Angular v18? Do you, by any chance, have a small repro I can look at?

1 Like

Hi,
Yes just recently upgraded to 18 and “@okta/okta-angular”: “^6.4.0”,
@okta/okta-auth-js”: “^7.7.0”, to the latest, I’ve changed it to use the forRoot() as well.

I don’t have a repo I can share.
I did some testing and found that it seems to be related to this, where it is being injected into the constructor of the authService.
Optional() Inject(OKTA_AUTH) private oktaAuth: OktaAuth,
(had to remove the @ from optional and Inject as I’m restricted being a new user

if I remove this line then the unit test will pass, which makes sense.

All the authorisation code was written prior me joining and I’m trying to pick it up, if you need me to test anything please let me know.

Hi Duncan,

Sorry, I’m having a little trouble following, so bear with me.

Were you able to resolve your issue? I can’t tell if you found a solution or not.

Are you running into the problem Younes mentions in this proposal?

Hi Alisa
Sorry, it’s difficult to explain, to test this I’ve converted my app.component.ts to use the inject() function (not in the constructor as mentioned in the GH ticket) and also changed the authService.service.ts to also use inject() and removed the constructor and any DI’s it had.

The unit test is really simple and just creates an instance of app.component.ts. The app.component.ts has an inject() to authService and this is now set up like
@Inject(OKTA_AUTH) private oktaAuth = inject(OktaAuth, { optional: true });

But the test still fails
FAIL src/app/app.component.spec.ts [ src/app/app.component.spec.ts ]
TypeError: Cannot read properties of undefined (reading ‘operators’)
❯ node_modules/okta/okta-angular/bundles/okta-okta-angular.umd.js:4:240

❯ node_modules/okta/okta-angular/bundles/okta-okta-angular.umd.js:5:3
❯ src/app/core/services/auth.service.ts:6:31

(@ symbols removed from node_modules/okta/okta-angular as I’m still restricted)

Test Files 1 failed (1)
Tests no tests
Start at 11:16:07
Duration 14.15s (transform 2.08s, setup 1.16s, collect 0ms, tests 0ms, environment 7.76s, prepare 8.86s)

as a side note, in the error above it refers to line 6:31, this is line 6, column 31 is the t in Injectable, not sure if this helps or not.
import { Inject, inject, Injectable, OnDestroy } from ‘@angular/core’;

Edit:
looking at the okta-okta-angular.umd.js file line 5:3 refers to
(this, (function (exports, i0, router, common, i2, operators, rxjs, compareVersions)
and I guess it’s this operators that it’s having issues with.

Thanks for the explanation, @Duncan .

It sounds like the SDK might need to be changed to support this. Do you agree?

If so, this should be a GH issue, which I’m happy to create and loop this post in unless you want to do so. Just LMK. If you create it, feel free to tag me. My GH username is @alisaduncan.

Here’s the GH repo issues link for the SDK

I do have one question though, just to make sure. When you use the inject function in the app.component.ts, do you also see the same error when you declare like this:

private oktaAuth = inject(OKTA_AUTH, { optional: true});

(I didn’t test the code so please excuse any syntax errors.)

I wrote a v17 standalone app with tests (but not Vitest), and this does run for me, but I’m not sure it is similar enough to your setup.

Hi Alisa,

Apologizes for not replying sooner but I was on an extended weekend break.

Let me take a look at your reply in more detail and I will get back to you with my findings.

Regards

Duncan

Hi

I’ve tried to declare this three different ways and it errors the same.

private oktaAuth = inject(OKTA_AUTH, { optional: true});
private oktaAuth = inject(OKTA_AUTH, { optional: true})!; ← nullable operator version

@Optional() @Inject(OKTA_AUTH) private oktaAuth: OktaAuth) {}

It’s also possible that we might not be using the OKTA services correctly, I need to compare your examples on GH with what we are doing.

I’m happy for you to raise a ticket for the SDK as I’m not sure I fully understand the issue with the SDK and what’s causing it.

Will keep chipping away at this and will update should I find anything

Hi,

I’ve been looking at the OKTA samples and see if I can get these working - in a completely separate project just to try and understand it.

All the examples I’ve found seem to refer to Angular 17, do you have any that work with Angular 18?

Hey @Duncan ,

Are you seeing problems when running Okta Angular in v18? I took my v17 app (the same one I linked above) and ran ng update. I can login, get profile info, etc. Is there a specific feature in v18 that’s causing a problem?

I am taking the same v17 project and trying to convert to Jest & Vitest to see if I can create a reproduction repo to submit an issue. I finally cleared out some backlog work so I can spend some time on this effort now. Were you able to resolve or uncover anything new?

Hi @alisaduncan ,

I’m not seeing issues with logging in (though I’ve had a couple while converting to a standalone application, but think I’ve got past that now I hope).

The main issue I was having, was with the unit tests (using vitest 1.6), where the component was referencing a service that has a reference to the OKTA library.

Thank you for your help on this, I’ve not been able to resolve this and so far and not discovered anything new.

Sorry to hear there are still issues, @Duncan .

I’m about to head out on PTO, but I try to get as far as I can in setting up a repro before I leave (and when I return).

@alisaduncan

Not a problem, it’s not urgent, but something I would like to resolve soon as I would like to start writing some unit tests.

Enjoy your PTO and we’ll catch up on your return.

Many thanks

Hi Alisa,

Hope you had a great holiday.

Just wondering if you have had any luck with the issue (see error below) when calling a unit test, bearing in mind that the unit tests (running vitest) aren’t actually doing anything as yet as you can see, it doesn’t affect all unit tests just a few

unit test imports here
describe(‘MyComponent’, () => {
let component: MyComponent;
let fixture: ComponentFixture;

beforeEach(async () => {
await TestBed.configureTestingModule({
imports: [MyComponent],
providers: [HttpClient, HttpHandler],
}).compileComponents();

fixture = TestBed.createComponent(MyComponent);
component = fixture.componentInstance;
fixture.detectChanges();

});

it(‘should create’, () => {
expect(component).toBeTruthy();
});
});

TypeError: Cannot read properties of undefined (reading ‘operators’)
node_modules/@okta/okta-angular/bundles/okta-okta-angular.umd.js:4:240

Thanks
Duncan

Hi @Duncan ,

Your post on adding Vitest helped me put together a sample. Can you confirm this is the same error you’re seeing?

Thanks!

Alisa,

That was a well timed post by all accounts, it’s had a really great response from the dev community.

I am looking at your repo now and will update you once I’ve got it running.

Alisa

I can confirm this is the error I am seeing - fingers crossed the fix is a simple one!

Hey @Duncan,

Well, I got my unit tests to run without the error, but I had to modify the package.json for the @okta/okta-angular library. It’s probably not what you’re hoping to hear, but there is a workaround. This error is a result of vitest running as Node and picking up Okta Angular library’s umd distribution instead of the esm distribution. Thanks for bringing this to our attention so we can prepare as more devs use vitest with Angular.

Please get latest from this repo

and add the following section to the @okta/okta-angular package.json

  "exports": {
    "./package.json": {
      "default": "./package.json"
    },
    ".": {
      "types": "./okta-okta-angular.d.ts",
      "esm2015": "./esm2015/okta-okta-angular.js",
      "esm": "./esm2015/okta-okta-angular.js",
      "default": "./fesm2015/okta-okta-angular.js"
    }
  },

Then I was able to run the tests without error.

I tried modifying the vite.config.mts prior to making the package.json change without luck, but you may be more familiar with the vitest configuration options to override a dependency import. I tried various alias and resolve configuration settings, and I couldn’t get it to work.

This GH issue on vitest repo covers the issue:

Their suggestion is to use the patch-package library to make changes until the library updates. If you discover a different workaround/configuration setting, I’d love to hear about it.

I noticed the ng-packagr does include the exports property by default in package.json in v18. I’ll bring this up with the SDK team to see how/when they want to handle the change. If I do end up creating an issue on it, I’ll make sure to tag you so you’re aware.

Thanks for your patience on this!

1 Like

Hi @Duncan !

One more thing. I checked with the SDK team and our Dev Support team on this. As a result of that discussion, I created a GH issue (and linked Jira for internal use). I tagged you on the GH issue:

If you can raise a support ticket to Okta on this (or have your customer raise one if they are the Okta customer you’re working with), then we can get support involved to escalate. Connecting a customer to a request helps with prioritization. :slightly_smiling_face:

Please mention this DevForum post, the GH issue, and the corresponding Jira number (OKTA-826555) so they have all the needed pieces to raise the concern.

Thanks and appreciate all your patience on this!

Alisa

Thank you, I will raise a support ticket.

Thank you for your support on this, really appreciated.

1 Like