Package subpath './lib' is not defined by "exports" about headers-polyfill HOT 13 CLOSED

Okay, there are two things to learn from this: don't import internal paths (./lib), and release ESM support as a breaking change, always.

Why does this happen?

You're using an old version of msw that depends on the old version of @mswjs/interceptors, which, in turn, has headers-polyfill/lib imports in its source. Since the interceptors pull the latest 3.x headers-polyfill, you get a package that has an explicit "exports" map where there's no ./lib export defined, causing the compilation error.

How do I fix this?

Update the msw version you're using. The original report above uses [email protected] which is an extremely old version.

npm i msw@latest --save-dev

You will get [email protected] (at the moment of writing this) and @mswjs/[email protected], which doesn't import the ./lib path anymore.

from headers-polyfill.

@TimClmd you probably try resolutions, it works for me.

  "resolutions": {
    "headers-polyfill": "3.0.10"
  }

from headers-polyfill.

Hacky solution for npm projects referencing version 3.1.0:

Modify the headers-polyfill package.json "exports" to include the subpath "./lib", pointing it to the index "./lib/index.js":

{
  "name": "headers-polyfill",
  "version": "3.1.0",
  "description": "A native \"Headers\" class polyfill.",
  "main": "./lib/index.js",
  "module": "./lib/esm/index.js",
  "types": "./lib/index.d.ts",
  "exports": {
    ".": {
      "types": "./lib/index.d.ts",
      "require": "./lib/index.js",
      "default": "./lib/esm/index.js"
    },
    "./lib": "./lib/index.js"
  },
  "repository": "https://github.com/mswjs/headers-polyfill",
  "author": "Artem Zakharchenko",
  "license": "MIT",
  "scripts": {
    "start": "tsup --watch",
    "clean": "rimraf lib",
    "build": "yarn clean && tsup",
    "test": "jest",
    "release": "release publish",
    "prepublishOnly": "yarn test && yarn build"
  },
  "files": [
    "lib",
    "README.md"
  ],
  "devDependencies": {
    "@ossjs/release": "^0.3.0",
    "@types/jest": "^28.1.4",
    "jest": "^28.1.2",
    "jest-environment-jsdom": "^28.1.2",
    "rimraf": "^3.0.2",
    "ts-jest": "^28.0.5",
    "tsup": "^6.2.3",
    "typescript": "4.3.2"
  }
}

from headers-polyfill.

@johnfrommartin Please reference this issue in your PR so it'll get resolved.

from headers-polyfill.

Thanks for reporting this. We need to get rid of /lib imports in @mswjs/interceptors.

from headers-polyfill.

Thanks for reporting this. We need to get rid of /lib imports in @mswjs/interceptors.

Do you have an ETA on when this will be fixed? We're seeing the same issue and reverting to previously-working version of mswjs does not fix as it's still pulling in version 3.1.2 here:

node_modules@mswjs\interceptors\node_modules\headers-polyfill

from headers-polyfill.

reverting to previously-working version of mswjs does not fix as it's still pulling in version

Had the same issue, you can just install [email protected] in your package.json until a fix comes through and it should resolve the issue. @TimClmd

from headers-polyfill.

reverting to previously-working version of mswjs does not fix as it's still pulling in version

Had the same issue, you can just install [email protected] in your package.json until a fix comes through and it should resolve the issue. @TimClmd

@DeclanBoller Thanks, yep I tried exactly this - it installed the correct version of headers-polyfill in the project's main node_modules folder, but mswjs still installed the newer version in its own node_modules folder as described, and this is what mswjs ends up using. Without mwjs's own package.json limiting the version, I'm not sure if it's possible to restrict this - is there a trick I don't know about to achieve this (searching on it, I'm not seeing a ton though it might just be I can't figure out how to ask the question right...)?

from headers-polyfill.

@qianyan

YES, thank you. That worked and gets us unstuck pending official resolution.

from headers-polyfill.

@TimClmd you probably try resolutions, it works for me.

  "resolutions": {
    "headers-polyfill": "3.0.10"
  }

Just a heads up for anyone else finding this workaround, resolutions is a Yarn feature and doesn't work with npm.

from headers-polyfill.

Just a heads up for anyone else finding this workaround, resolutions is a Yarn feature and doesn't work with npm

NPM users on v8 can use overrides to the same effect
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides

npm ls headers-polyfill to verify the override is applied.

from headers-polyfill.

Created a PR to fix this, adding './lib' as an export subpath here.

from headers-polyfill.

@johnfrommartin Please reference this issue in your PR so it'll get resolved.

@acdvs Done

from headers-polyfill.