Cannot read properties of undefined (reading 'operators')

Duncan · August 21, 2024, 12:40pm

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

alisaduncan · August 21, 2024, 3:02pm

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?

Duncan · August 21, 2024, 3:21pm

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.

alisaduncan · August 22, 2024, 12:10am

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?

github.com/angular/angular

Allow `inject()` usage as constructor parameter properties default

opened 08:15AM - 03 Oct 22 UTC

yjaaidi

area: core core: di P2

### Which @angular/* package(s) are relevant/related to the feature request? co…mpiler-cli, compiler ### Description ## Transformer in the way Injectables' dependencies are currently guessed by analyzing the constructor parameter types. This typing information is lost after transforming TypeScript to ECMAScript. In order to fix this, the compiler has to run a transformer that converts this information into something like: ```ts MyCmp.ctorParameters = () => [ { type: MyService } ]; ``` Cf. https://github.com/angular/angular/blob/3a60063a54d850c50ce962a8a39ce01cfee71398/packages/compiler-cli/src/transformers/downlevel_decorators_transform/downlevel_decorators_transform.ts The problem with this approach is that it slows down community initiatives of integrating Angular with other tools. e.g. Vite, Vitest, SWC... This forces tools to hack their way through. For instance, jest-preset-angular downloads the internal CLI transformer: https://github.com/thymikee/jest-preset-angular/blob/f24156ea1f7532c02c44d8d023b54623a4bccccd/scripts/prebuild.js#L9 ## `inject()` to the rescue The good news is that an app using only `inject()` instead of constructor param types to retrieve dependencies will not need this transformer: ```ts class MyCmp { myService = inject(MyService); } ``` The problem with using `inject()` function this way is that it doesn't allow injecting dependencies manually. This means that all tests will need the `TestBed` or similar to control dependencies resolution. To allow manual instantiation, the current alternative would be something **non-explicit, verbose and error-prone** like this: ```ts class MyCmp { // let's not do this constructor(myService?: MyService) { this.myService = myService ?? inject(MyService); } } ``` ### Proposed solution Compiler should bypass type-based dependency injection when a default value is set and the given type can't be resolved. This would allow the following syntax which currently works if this transformer is disabled: ```ts class MyCmp { constructor(private myService = inject(MyService)) {} } ``` This has the following advantages: - ✨ constructor parameters transformer is not needed anymore... so easier integration with existing tools - ✨ manual instantiation is still possible - ✨ all the benefits of `inject`: type-inference, consistent way of injecting class-based & injection-token based deps: `locale = inject(LOCALE_ID)`, controlling options (e.g. optional, self) through flags instead of decorators. ### Alternatives considered Use `inject()` and never instantiate manually.

Duncan · August 22, 2024, 10:27am

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.

alisaduncan · August 23, 2024, 7:31pm

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.

github.com

oktadev/okta-angular-standalone-runtime-config-example/blob/main/src/app/app.component.ts

import { AsyncPipe } from '@angular/common';
import { Component, inject } from '@angular/core';
import { RouterLink, RouterOutlet } from '@angular/router';
import { OktaAuthStateService, OKTA_AUTH } from '@okta/okta-angular';
import { AuthState } from '@okta/okta-auth-js';
import { filter, map } from 'rxjs';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [AsyncPipe, RouterOutlet, RouterLink],
  templateUrl: './app.component.html',
  styleUrl: './app.component.scss'
})
export class AppComponent {
  private oktaStateService = inject(OktaAuthStateService);
  private oktaAuth = inject(OKTA_AUTH);

  public isAuthenticated$ = this.oktaStateService.authState$.pipe(
    filter((s: AuthState) => !!s),

This file has been truncated. show original

Duncan · August 28, 2024, 8:35am

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

Duncan · August 28, 2024, 10:42am

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

Duncan · August 30, 2024, 4:12pm

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?

alisaduncan · September 10, 2024, 9:06pm

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?

Duncan · September 11, 2024, 9:07am

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.

alisaduncan · September 11, 2024, 2:13pm

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).

Duncan · September 11, 2024, 3:05pm

@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