awslabs / aws-jwt-verify

JS library for verifying JWTs signed by Amazon Cognito, and any OIDC-compatible IDP that signs JWTs with RS256, RS384, RS512, ES256, ES384, and ES512
Apache License 2.0
621 stars 44 forks source link

[BUG] Could not resolve "#node-web-compat" #88

Closed F43nd1r closed 2 years ago

F43nd1r commented 2 years ago

Describe the bug I'm facing another version of #66 in combination with yarn berry and esbuild. Build fails with

X [ERROR] Could not resolve "#node-web-compat"

    .yarn/cache/aws-jwt-verify-npm-3.1.0-1694314cd9-b978817018.zip/node_modules/aws-jwt-verify/dist/esm/jwt-rsa.js:8:30:
      8 │ import { nodeWebCompat } from "#node-web-compat";
        ╵                               ~~~~~~~~~~~~~~~~~~

  You can mark the path "#node-web-compat" as external to exclude it from the bundle, which will
  remove this error.

Workaround is to use a different linker mode in yarn, e.g. pnpm

Versions Which version of aws-jwt-verify are you using? ^3.1.0 Are you using the library in Node.js or in the Web browser? Node.js If Node.js, which version of Node.js are you using? (Should be at least 14) 14 If Web browser, which web browser and which version of it are you using? If using TypeScript, which version of TypeScript are you using? (Should be at least 4) ^4.8.3

To Reproduce Reproducer can be found here.

Note: I'm not sure where to report this issue, could as well be in yarn or esbuild. I'm just starting here, hoping you can point me further.

ottokruse commented 2 years ago

Indeed a variant (or duplicate) of #66

aws-jwt-verify uses subpath imports which unfortunately has flaky support in various tools and libs (looking at you jest). Although esbuild has supported it since version 0.13.9 (see https://github.com/evanw/esbuild/issues/1691)

    "imports": {
        "#node-web-compat": {
            "browser": "./node-web-compat-web.js",
            "import": "./node-web-compat-node.js"
        }
    }

The culprit must be the specific interplay of yarn with esbuild, concerning subpath imports. My stack trace shows:

Error: Command failed: /private/tmp/yarn-berry-esbuild-aws-jwt-verify-reproducer/node_modules/.cache/esbuild/pnpapi-esbuild-darwin-64-0.15.7-esbuild --bundle ./src/index.ts --target=node14 --platform=node --outfile=./build/out.js --charset=utf8
    at checkExecSyncError (node:child_process:828:11)
    at Object.execFileSync (node:child_process:863:15)
    at Object.<anonymous> (/private/tmp/yarn-berry-esbuild-aws-jwt-verify-reproducer/.yarn/unplugged/esbuild-npm-0.15.7-9aee421406/node_modules/esbuild/bin/esbuild:183:28)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Object.require$$0.Module._extensions..js (/private/tmp/yarn-berry-esbuild-aws-jwt-verify-reproducer/.pnp.cjs:9008:33)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.require$$0.Module._load (/private/tmp/yarn-berry-esbuild-aws-jwt-verify-reproducer/.pnp.cjs:8848:14)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12) {
  status: 1,
  signal: null,
  output: [ null, null, null ],
  pid: 59761,
  stdout: null,
  stderr: null
}

I recommend to open an issue with esbuild.

We can keep this issue here open for now, but it will need convincing that this is an issue in our library.

F43nd1r commented 2 years ago

reported to esbuild as https://github.com/evanw/esbuild/issues/2545, will keep you updated if it affects this package.

F43nd1r commented 2 years ago

Found out it is a missing feature in yarn https://github.com/yarnpkg/berry/issues/3843. I'll close this as I expect it to work once that is implemented.

If someone else lands here: Go and :+1: that issue so we can get this working

mrienstra commented 2 years ago

yarnpkg/berry#3843 was fixed yesterday. The fix is available in 4.0.0-rc.22. Run yarn set version canary if you want to try it. v4 release is still a little ways off ("may take a couple more months"), but:

[...] what's in master is stable, and I'd recommend you to try it. The only notable difference with stable is that we reserve the right to land a couple more breaking changes in future RCs, but in terms of stability it's almost always better to use RCs than stable.

... according to https://github.com/yarnpkg/berry/discussions/4895

See https://github.com/yarnpkg/berry/issues/3591 for v4 breaking changes. I've seen two mentions of people stumbling over enableGlobalCache default changing from false to true. (Google search: site:yarnpkg.com "enableGlobalCache")

mrienstra commented 1 year ago

Update: the fix that adds support for the package.json includes field is also in the Yarn 3.2.4 release.