next-auth: Error: No known conditions for "./react" entry in "next-auth" package

So I think we should actually not use the “import” conditional export type in our export map.

Yes this is exactly with what I am in trouble.

After reading more about conditional exports, it’s recommended when using “import” condition to also provide “require” (which is mutually exclusive with “import”) or “default” which matches any environment. Otherwise we end up to not be able to resolve those exports when a build is transpiled to CommonJS format and using a modern NodeJS runtime (taking into account exports field). That is also the case with yarn PNP resolver which will strictly follow the conditional exports.

I don’t know about Skypack, but as long as we get only one target to use, we could go back with.

"exports": {
  ".": "./index.js",
  "./jwt":  "./jwt/index.js",
  "./react": "./react/index.js",
  "./providers/*": "./providers/*.js"
},

Conditional exports are meant to specify different paths like this

"exports": {
  ".": {
    "import": "./dist/es/index.js",
    "require": "./dist/cjs/index.js",
    "default": "./dist/es/index.js"
  },
  "./feature": {
    "import": "./dist/es/feature/index.js",
    "require": "./dist/cjs/feature/index.js",
    "default": "./dist/es/feature/index.js"
  }
},

By the way, apart from that issue, a fork of next-auth@beta with a quick fix for exports field, is working very well with yarn@canary with pnp.

I see. I’ll close this issue since #2830 was merged and #2767 then since it seems unnecessary for now. We can revisit the concept when we are able to generate multiple bundles for different targets.

The PR #2830 looks good to me. We should use conditional exports only when we truly need to resolve distinct paths given one subpath pattern.

My first suggestion was based on my poor knowledge about the exports field. But After looking into it in details, it doesn’t make sense to use conditional exports if all the conditions lead to the same target.

@balazsorban44 okay before the v4 GA release, do we maybe want to change the export map to either:

"exports": {
    ".": {
      "import": "./index.js",
      "default": "./index.js"
    },
    "./jwt": {
      "import": "./jwt/index.js",
      "default": "./jwt/index.js"
    },
    "./react": {
      "import": "./react/index.js",
      "default": "./react/index.js"
    },
    "./providers/*": {
      "import": "./providers/*.js",
      "default": "./providers/*.js"
    }
  }

Or the “default” export:

"exports": {
    ".": "./index.js",
    "./jwt":  "./jwt/index.js",
    "./react": "./react/index.js",
    "./providers/*": "./providers/*.js"
  }

Skypack seems to only car that theres a toplevel export map existent at all in the package.json (https://docs.skypack.dev/package-authors/package-checks#export-map)

Hmm yeah I’d be curious if adding the node/require export map option, in addition to import, would affect the skypack score at all.

I’m more curious though as to why in my one environment and apparently @Stouffi’s, it was transpiled and imported as cjs serverside when that doesn’t seem to be the case for most users / environments 🤔

As a quick fix / workaround I think adding node / require to the export map would be okay. Fred specifically mentions this use case in one section of the docs you linked as well (https://docs.skypack.dev/package-authors/package-checks#how-to-fix-1) so hopefully should affect the score to add node/require in addition to import in the export map (damn what a tongue twister 😅)