Update oidc-provider library to v8

[joachimvh]

📁 Related issues

Closes #1304

✍️ Description

Updates the oidc-provider library to v8. There are several issues with this upgrade though, which require several hacky solutions to solve, so I'm not sure yet if this is the solution to go with and if perhaps some more of it can be automated.

The new version of oidc-provider is an ESM package. CSS is a CJS package though, and combining those two introduces several issues. Adding TypeScript and Jest to the mix complicates it even further. Some of the problems, not all though, could be avoided by making CSS an ESM package as well, but that would complicate things for people who use it as a dependency so I would prefer not to do that.

The issues are each described and resolved in the separate commits, but I'll also list them below.

1. ESM packages need to be dynamically imported in CJS

The only way to use an ESM package in CJS is by doing a dynamic import, see https://nodejs.org/api/esm.html#import-expressions. This means that to create the OIDC provider we now need the following line:

const provider = new (await import('oidc-provider')).default(this.baseUrl, config);

2. TypeScript settings need to change to support dynamic imports

By default TypeScript converts the dynamic imports to require statements, which would break the ESM import. To keep the dynamic import correct, moduleResolution needs to be set to node16. I don't think this has any consequences for packages depending on CSS so this should be fine.

Related issue: microsoft/TypeScript#43329

3. TypeScript has an issue with types from ESM packages

TypeScript also requires dynamic imports for all the typings of an ESM package. This would make the typings mostly unusable though. This is an open issue: microsoft/TypeScript#49721

To work around this, I copied the typing file to a local file and use that as typings for now, fooling TypeScript into thinking these are independent of the ESM package, and also showing there is no reason TypeScript shouldn't support this.

4. Jest support for ESM dependencies isn't perfect

There are several ways to work around the issues Jest has with such dependencies, but the easiest one seems to be to transform those packages into CJS before Jest interprets them. The jest config has been updated to use such a transformer, jest-esm-transformer-2, targetting a list of ESM dependencies. That list was found by starting from oidc-provider and always adding the next package that results in an error.

5. Jest has segmentation faults when using dynamic imports

This is a bug in Node.js with the components Jest uses: nodejs/node#35889.

To work around this, the dynamic import of oidc-provider in IdentityProviderFactory is handled differently when Jest is running. Environment variables are checked to see if the code is being run in Jest, if yes, a specific Jest import is used instead of a dynamic import, preventing the segmentation fault.

For the unit tests, a different tsconfig.json is used that does not have the new moduleResolution value to prevent Jest issues there.

6. There is a bug in the authn client

See inrupt/solid-client-authn-js#2985. This is nothing major as it does not require a major fix in the library, but does prevent the CSS tests from succeeding currently.

[elf-pavlik]

could be avoided by making CSS an ESM package as well, but that would complicate things for people who use it as a dependency so I would prefer not to do that.

Lack of support for ESM in Component.js could also make it harder

• ESM support LinkedSoftwareDependencies/Components.js#83

[TallTed]

minor tweaks to comments for clarity

[elf-pavlik]

Is this PR blocked by inrupt/solid-client-authn-js#2985 ?

[joachimvh]

Is this PR blocked by inrupt/solid-client-authn-js#2985 ?

Yes as long as that isn't fixed the authn library won't work with the new version. The browser version of the library will work as the issue was fixed there in the past, the problem is with the node version of the library.

[joachimvh]

I've added a workaround for the authn issue so the CSS integration tests can pass until the issue is fixed. So will look into merging this and the node v18 stuff soon. This will break client implementations that use the node.js version of the library until the issue is fixed, but a similar workaround could be used there. As far as I know most client applications use the browser version so should hopefully not have too much impact.