replace crypto-js

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

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

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