'decode' is not exported from '@ipld/dag-cbor'

[luizoamorim]

I'm using nft.storage in my project. This library have ipld dependence.

I've got this error when I try generate a project build:

./node_modules/@ipld/car/esm/lib/decoder.js Attempted import error: 'decode' is not exported from '@ipld/dag-cbor' (imported as 'decodeDagCbor').

Can somebody help me?

[rvagg]

What environment are you trying to build and run this in @luizoamorim? This wouldn't be Jest would it? You're possibly using an environment that doesn't support export maps properly but there should be workarounds.

[sicktastic]

I got the same error using nft.storage with next.js and it fails during build time. Did anyone found the workaround yet?

[rvagg]

Can you provide some code to reproduce this? We have a lot of folks (including myself for percid.va.gg) using this code directly via next.js and other frameworks and nft.storage and web3.storage without these problems, so there must be something specific about the environment that's causing a hiccup. Can you describe the toolchain and setup in a way that might help us narrow it down?

[fungilation]

I'm stuck with this issue. TLDR of https://github.com/ipfs-shipyard/nft.storage/issues/215#issuecomment-932806972: I have to downgrade nft.storage from 3.x to 2.x, in order to completely avoid the @ipld/dag-cbor dependency. Otherwise, I find no other way to avoid next build error:

$ npm run build

> next build

info  - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
info  - Checking validity of types

info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info  - Creating an optimized production build
Failed to compile.

./node_modules/@ipld/car/esm/lib/decoder.js
Attempted import error: 'decode' is not exported from '@ipld/dag-cbor' (imported as 'decodeDagCbor').

> Build error occurred
Error: > Build failed because of webpack error

My package.json:

{
  ...
  "dependencies": {
    "@nomiclabs/hardhat-ethers": "^2.0.2",
    "@nomiclabs/hardhat-waffle": "^2.0.1",
    "@openzeppelin/contracts": "^4.3.1",
    "axios": "^0.21.4",
    "chai": "^4.3.4",
    "ethereum-waffle": "^3.4.0",
    "ethers": "^5.4.6",
    "hardhat": "^2.6.4",
    "moralis": "^0.0.67",
    "next": "11.1.2",
    "nft.storage": "^2",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-moralis": "^0.2.3",
    "web3modal": "^1.9.4"
  },
  "devDependencies": {
    "@types/node": "^16.6.1",
    "@types/react": "^17.0.15",
    "@types/react-dom": "^17.0.9",
    "@types/react-redux": "^7.1.18",
    "autoprefixer": "^10.3.4",
    "eslint": "7.32.0",
    "eslint-config-next": "11.1.2",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^4.0.0",
    "postcss": "^8.3.6",
    "prettier": "^2.3.2",
    "stylelint": "^13.13.1",
    "stylelint-config-recommended": "^5.0.0",
    "tailwindcss": "^2.2.15",
    "ts-node": "^10.2.0",
    "typescript": "4.4.3"
  }
}

[rvagg]

If someone experiencing this can provide a very simple reproduction they can share, maybe just a basic project that doesn't build, shared as a repo or some other way, that would be extremely helpful in narrowing this down. Having to support so many permutations of build environment makes this a bit tricky to isolate without help.

[yusefnapora]

@rvagg there's an example in this comment from the related issue.

It does fail to build, but if I delete the package-lock.json and try to reinstall I can't reproduce the error with either node v16.5.0 or v14.17.3. I also tried yarn after deleting the package-lock.json and it built without an error also.

Perhaps relevant: I also tried copying all the dependencies and devDependencies from the failing project to the "noerrror" project, but I wasn't able to reproduce the error that way either.

All this was tested on an M1 MacBook Air - the node 16 build is ARM-native, but v14 is emulated through Rosetta.

Anyway, no conclusions, but maybe that will help rule some things out.

@fungilation if you could put up a repo that demonstrates the issue that would help. Your OS and node.js version may be relevant also.

[LAMike310]

@rvagg @yusefnapora I found this issue trying to code with the demo of Next.js

Here's my steps to reproduce:

git clone https://github.com/ipfs-examples/js-ipfs-browser-nextjs.git cd js-ipfs-browser-nextjs && npm i next build

And get this result:

Attempted import error: 'decode' is not exported from '@ipld/dag-cbor' (imported as 'dagCbor')

I get this error using both 16.5.0 and 14.17.3 node versions, and npm version 6.14.13

Thanks for looking into this!

[LAMike310]

When I tried npm start, I got this error, which is why I tried next build:

'/Volumes/SSD/Code/clipana/backend/js-ipfs-browser-nextjs/.next' directory. Try building your app with 'next build' before starting the production server.

[theshadowagent]

Still running into this with next.js, any update?

[rvagg]

@achingbrain suspected this might be related to https://github.com/webpack/webpack/discussions/14268 which was about a very similar problem in our stack.

https://github.com/webpack/enhanced-resolve/issues/304 is related and lead to https://github.com/webpack/enhanced-resolve/pull/305 in enhanced-resolve.

I've used @LAMike310's suggestion for how to replicate the problem (with js-ipfs-browser-nextjs - can confirm, it breaks, thanks @LAMike310!), and have applied the fix for enhanced-resolve's getInnerRequest to ./node_modules/next/dist/compiled/webpack/bundle5.js, and after deleting .next/cache/ and re-running the build, it works.

So it's to do with our heavy reliance on export maps and the "." (implicit and explicit) mapping we have in our various packages that use this same pattern. I'm not quite sure how differences in npm vs yarn vs package-lock.json etc. come in to play as has been mentioned in the various threads about this topic. Something to do with relative path from importer to exporter I suppose—I don't know how that relates to export maps though!

So enhanced-resolve has a fix. But unfortunately that needs to bubble from there to webpack and to nextjs. And as mentioned in https://github.com/webpack/enhanced-resolve/issues/304#issuecomment-925685401, it's not going to be backported.

[theshadowagent]

Easy FIX: I just updated next from 11.1.2 to 12, deleted .next and yarn.lock, and the problem went away

[rvagg]

closing because this seems to have been fixed by toolchain updates