v0.13.0 breaks existing NextJS build due to main vs. module change:

[CinchBlue]

🐛 Bug description

When building using v0.13.0 vs. v0.12.1, our existing NextJS/wasm-pack build process will break within CI with an opaque error message.

Run npm run build

> app@0.1.0 build
> next build

  ▲ Next.js 14.2.4

   Linting and checking validity of types ...
   Creating an optimized production build ...
created symlink /runner/_work/app/app/.next/server/static -> /runner/_work/app/app/.next/server/chunks/static
created symlink /runner/_work/app/app/.next/static -> /runner/_work/app/app/.next/server/static
Failed to compile.

Error: ENOENT: no such file or directory, mkdir '/runner/_work/app/app/.next/static/media'

🤔 Expected Behavior

It should continue to work?

👟 Steps to reproduce

Use a package.json that looks like this, then try to use an NPM package build with wasm-pack 0.13.0 with this:

package.json

{
  "name": "app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "rm -Rf .next && next dev",
    "prod": "SENTRY=true next build",
    "build": "next build",
    "start": "next start",
    "lint": "next lint --max-warnings=0",
    "tsc": "tsc -p tsconfig.json --noEmit",
    "prepare": "husky",
  },
  "dependencies": {
    "@my-org/app": "1234.467.890",
    "big.js": "6.2.1",
    "@sentry/nextjs": "8.11.0",
    "next": "14.2.4",
  },
  "devDependencies": {
    "@emotion/babel-plugin": "11.11.0",
    "@emotion/eslint-plugin": "11.11.0",
    "@next/bundle-analyzer": "14.2.4",
    "@svgr/webpack": "8.1.0",
    "@typescript-eslint/eslint-plugin": "7.13.1",
    "@typescript-eslint/parser": "7.13.1",
    "eslint": "8.57.0",
    "eslint-config-next": "14.2.4",
    "husky": "9.0.11",
    "prettier": "3.3.2",
    "ts-node": "10.9.2",
    "typescript": "5.5.2"
  },
}

tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "sourceMap": true,
    "noUnusedLocals": true /* Report errors on unused locals. */,
    "noUnusedParameters": true /* Report errors on unused parameters. */,
    "noImplicitReturns": true /* Report error when not all code paths in function return a value. */,
    "noFallthroughCasesInSwitch": true /* Report errors for fallthrough cases in switch statement. */,
    "paths": {
      "@src/*": ["./src/*"],
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: 0.13.0
rustc version: rustc 1.79.0-nightly (385fa9d84 2024-04-04)
npm version: 18.17.0

[CinchBlue]

This seems related to this change in v0.13.0:

• Declare ES module in package.json - gthb, Add type = "module" in package.json to support nodejs in bundler mode #1039, fix: declare ES module in package.json #1061

[IceTDrinker]

can confirm this change is causing some issues on our end (the change of declared module type), is there a way to select the type of the output package ?