Webpack build fails with version 0.32.0 with error "Default condition should be last one"

[colatkinson]

A minimal repro is something like:

$ cat ./index.mjs
import { Type } from "@sinclair/typebox"

$ npx webpack --mode production --entry ./index.mjs
assets by status 137 bytes [cached] 1 asset
./index.mjs 41 bytes [built] [code generated]

ERROR in ./index.mjs 1:0-40
Module not found: Error: Default condition should be last one

webpack 5.89.0 compiled with 1 error in 242 ms

This seems to be a pretty common issue across many packages, see e.g. https://github.com/pixijs/pixijs/issues/9691, https://github.com/firebase/firebase-js-sdk/issues/7005, https://github.com/vuetifyjs/vuetify/issues/17436.

This is with node 18.18.0.

So far as I can tell, this is the origin of the error: https://github.com/webpack/enhanced-resolve/blob/58464fc7cb56673c9aa849e68e6300239601e615/lib/util/entrypoints.js#L475

As far as I can tell, the fix is simply to make sure that default is the last key in each exports entry in the package.json. I tested it locally, and it appears to resolve the issue. Please let me know if there's any additional information I can provide.

[sinclairzx81]

@colatkinson Hi, Thanks for reporting (and for the reference links)

Yes, this is quite the surprising requirement. I have just published 0.31.1 which ensures the default import target is specified last in the package.json. Below is the published order.

{
 ...
  "types": "./build/require/index.d.ts",
  "main": "./build/require/index.js",
  "module": "./build/import/index.mjs",
  "exports": {
    ".": {
      "require": {
        "types": "./build/require/index.d.ts",
        "default": "./build/require/index.js"
      },
      "import": {
        "types": "./build/import/index.d.mts",
        "default": "./build/import/index.mjs"
      }
    },
    "./compiler": {
      "require": {
        "types": "./build/require/compiler/index.d.ts",
        "default": "./build/require/compiler/index.js"
      },
      "import": {
        "types": "./build/import/compiler/index.d.mts",
        "default": "./build/import/compiler/index.mjs"
      }
    },
    "./errors": {
      "require": {
        "types": "./build/require/errors/index.d.ts",
        "default": "./build/require/errors/index.js"
      },
      "import": {
        "types": "./build/import/errors/index.d.mts",
        "default": "./build/import/errors/index.mjs"
      }
    },
    "./system": {
      "require": {
        "types": "./build/require/system/index.d.ts",
        "default": "./build/require/system/index.js"
      },
      "import": {
        "types": "./build/import/system/index.d.mts",
        "default": "./build/import/system/index.mjs"
      }
    },
    "./type": {
      "require": {
        "types": "./build/require/type/index.d.ts",
        "default": "./build/require/type/index.js"
      },
      "import": {
        "types": "./build/import/type/index.d.mts",
        "default": "./build/import/type/index.mjs"
      }
    },
    "./value": {
      "require": {
        "types": "./build/require/value/index.d.ts",
        "default": "./build/require/value/index.js"
      },
      "import": {
        "types": "./build/import/value/index.d.mts",
        "default": "./build/import/value/index.mjs"
      }
    }
  }

If you can test this against your WebPack installation and let me know this resolves the issue, can close this one off.

Thanks again for reporting S

[sinclairzx81]

@colatkinson Hey,

I actually note this configuration update solved another issue I was facing getting the vscode import-cost plugin to correctly evaluate import sizes (where it seems the plugin may be internally using WebPack to evaluate estimated bundle size). Not being a WebPack user, I had no idea why, but seemed to be related to this issue.

[sinclairzx81]

@colatkinson Hiya,

Going to close off this issue as the key order has been resolved on 0.32.1. Feel free to ping on this thread if you're still encountering issues.

Cheers! S

[colatkinson]

Hi, sorry for the delayed response. Just wanted to confirm that 0.32.1 does appear to fix the issue. Thanks for looking into it!