replace crypto-js

[Badisi]

When using oidc-client-ts in an Angular application, the following warning is raised:

Warning: node_modules/oidc-client-ts/dist/esm/oidc-client-ts.js depends on 'crypto-js/enc-base64.js'. CommonJS or AMD dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

There is a solution to explicitely make the warning silent in the application :

"architect": {
    "build": {
        "options": {
            "allowedCommonJsDependencies": [
                "crypto-js"
            ]
        }
    }
}

But I was thinking that, maybe, oidc-client-ts could simply migrates to crypto-es. What do you think ?

Because unfortunately crypto-js doesn't seem to care about moving to es module.. #60 and #236

[pamapa]

When i was introducing crypto-js i was already aware of crypto-es and decided for crypto-js for several reasons:

• https://www.npmtrends.com/crypto-js-vs-crypto-es
• more active maintained
• much much more usage
• even if its not esm, you can add only those parts you need

[kherock]

I don't like to argue popularity as the primary reason for choosing one over another, but in this case I do fear that crypto-es doesn't have enough eyes on it, and ultimately this library won't gain much from switching to it. We already use deep imports which provides most of the advantage that tree-shaking the ES modules port would provide.

Looking forward, we should be able to eventually use the Web Crypto APIs directly. There are projects like webcrypto-liner which might let us move off of crypto-js sooner while we wait for ubiquitous webcrypto support, but for now I think the safest option is to continue using crypto-js.

[pamapa]

Crypto.subtle would be really nice and natively supported, but it only working in a secure context (HTTPS), which makes it useless for development proposes where most people operate with HTTP. This will be a pity in the very long run. I would really prefer native (browser + nodejs) support, which is currently not possible :-(

webcrypto-liner or an other lightweight wrapper library might help here as well.

[drk-mtr]

As an aside, these days I tend to use https for development, because if I don't I end up hitting too many CORS issues - so I find it's easier to "bite the bullet" and just use https throughout.

[CorporateActionMan]

@pamapa this is a really great library in our team and we would like to plus one 👍 this feature request

[43081j]

@pamapa this also effects esm-only environments (e.g. native browser modules).

currently it isn't possible to use oidc-client-ts in a browser natively because crypto-js ships commonjs. the benefits of oidc-client shipping an esm entrypoint go out of the window because of that.

do you have any suggestions for how this could be moved forward?

unless you plan on contributing ESM upstream to crypto-js, it looks like whatever solution you choose will result in dropping that package. if alternatives have downsides, they're probably worth it compared to this package being useless without a bundler.

happy to help figure it out if needed

[pamapa]

@43081j Have you tried https://cdnjs.com/libraries/oidc-client-ts?

[43081j]

to what end?

it isn't really a solution to move off npm to using CDNs for dependencies. and even if we did that somehow, the only CDNs that'd work are themselves running bundlers internally.

ultimately, crypto-js doesn't work natively in browsers (it is a commonjs module). therefore, oidc-client-ts doesn't work natively in browsers.

the only solutions really are to make crypto-js work in browsers (contribute upstream so they publish a browser entrypoint) or move off crypto-js to something which already works in browsers.

of course, bundlers can solve this by transforming commonjs dependencies into es modules. but we shouldn't really put constraints on consumers' workflows to be able to use this package.

its not a straight forward problem to solve though, i understand.