No “exports” main defined in @monogrid/gainmap-js

[drcmda]

now that monogrid is in drei users experience issues with bundling environments like next-js.

https://discourse.threejs.org/t/trying-to-use-react-three-drei-in-next-js-error-no-exports-main-defined-in-monogrid-gainmap-js-package-json/63586

Server Error
Error: No “exports” main defined in /Users/primozrome/Documents/WEB/dewesoft-website/node_modules/@monogrid/gainmap-js/package.json
This error happened while generating the page. Any console logs will be displayed in the terminal window.

[daniele-pelagatti]

is this solved by adding something like this?

  "exports": {
    ".": {
      "import": "./dist/decode.js",
      "main":  "./dist/decode.umd.js", <----------
      "types": "./dist/decode.d.ts"
    },
    "./encode": {
      "import": "./dist/encode.js",
      "main":  "./dist/encode.umd.js", <----------      
      "types": "./dist/encode.d.ts"
    },
    "./libultrahdr": {
      "import": "./dist/libultrahdr.js",
      "main":  "./dist/libultrahdr.umd.js", <----------      
      "types": "./dist/libultrahdr.d.ts"
    },
    "./worker": {
      "import": "./dist/worker.js",
      "main":  "./dist/worker.umd.js", <----------            
      "types": "./dist/worker.d.ts"
    },
    "./worker-interface": {
      "import": "./dist/worker-interface.js",
      "main":  "./dist/worker-interface.umd.js", <----------                  
      "types": "./dist/worker-interface.d.ts"
    }
  },

I'm not sure what's the proper fix, I have no trouble bundling with vite

[daniele-pelagatti]

or maybe I need to name the files .mjs

[...]
  "exports": {
    ".": {
      "import": "./dist/decode.mjs",
      [...]
    }
[...]

:thinking: I'm trying to reproduce the problem with https://github.com/pmndrs/react-three-next

[drcmda]

good idea! i hope this is just a fluke. esm exports package.json is so complicated, i would not know how to even publish a package nowadays.

[CodyJasonBennett]

See https://publint.dev/@monogrid/gainmap-js@3.0.4. It should be (note the use of .cjs):

"main": "dist/decode.umd.cjs",
"module": "dist/decode.js",
"types": "dist/decode.d.ts",
"sideEffects": false,
"type": "module",
"exports": {
  ".": {
    "types": "./dist/decode.d.ts",
    "import": "./dist/decode.js",
    "default":  "./dist/decode.umd.cjs"
  },
  "./encode": {
    "types": "./dist/encode.d.ts",
    "import": "./dist/encode.js",
    "default":  "./dist/encode.umd.cjs"
  },
  "./libultrahdr": {
    "types": "./dist/libultrahdr.d.ts",
    "import": "./dist/libultrahdr.js",
    "default":  "./dist/libultrahdr.umd.cjs"
  },
  "./worker": {
    "types": "./dist/worker.d.ts",
    "import": "./dist/worker.js",
    "main":  "./dist/worker.umd.cjs"
  },
  "./worker-interface": {
    "types": "./dist/worker-interface.d.ts",
    "import": "./dist/worker-interface.js",
    "default":  "./dist/worker-interface.umd.js"
  }
},

[daniele-pelagatti]

Ok, I kinda trust you but I wasn't able to reproduce the problem with a clean https://github.com/pmndrs/react-three-next initialization with the "untouched" library and a yarn build produced no error @CodyJasonBennett can you confirm this would fix the problem? or point me to a reproducibility procedure? I'm the kind of guy that likes to avoids "blind fixes" if possible

[CodyJasonBennett]

The reason this issue occurred was because Node tried to resolve your package from a CJS entrypoint (Next.js server-side), but the package only specifies the import condition (ESM-only). Since Node 14, it reads from the exports field over main when present (module is a Webpack-only field).

The use of .cjs or .mjs overrides the type key which controls which resolver Node should use for .js extensions. So, for an ESM package with "type": "module", you can use .cjs to specify a CJS entrypoint, and anything ending with .js is assumed to be ESM.

I couldn't clone this repository to implement this fix myself, but was referred here due to a downstream issue when resolving with Next.js, presumably through their app directory which uses a different compiler than our Next.js integration tests. https://publint.dev exists and can be used locally via CLI to ensure your package satisfies Node's increasingly complicated API contract.

[daniele-pelagatti]

Okay then, I've opened #36 with the fix you proposed, will be merging soon

[daniele-pelagatti]

v3.0.5 is out https://publint.dev/@monogrid/gainmap-js@3.0.5 seems fine, let me know if this solves this problem, thanks for the help!

[daniele-pelagatti]

I'm going to close this as no-one else reported a similar problem. If this problem resurfaces please feel free to open again, thanks everyone