chore: update ipfs #43
Conversation
The next ipfs release will be a dual ESM/CJS version which is presenting some interesting challenges for all the different tools used here. We also use the `ipfs` module everywhere when we could be using `ipfs-core` instead - it's lighter and much quicker to install. Really we should only use `ipfs` when we need the CLI and the HTTP RPC API, though I'm a little wary of the potential confusion for new users having two options introduces. Todo: - [ ] Release js-ipfs - [ ] Replace `'next'` dep versions with actual releases
|
Sounds good. To address the "potential confusion for new users" we could update the root Btw, this means that it might be possible to integrate with rollup with the new release? (and other ESModules oriented bundlers and frameworks) |
That could be work, if you think people will read it. I guess the danger is the per-example repos won't have that README in them?
Give a try? js-ipfs will be ESM-friendly, but it depends on modules that are CJS so that may cause problems. |
|
@oliveriosousa the fix in webpack/enhanced-resolve#304 solved the build problems for most of the examples, the only problem is nextjs distributes a bundled version of webpack instead of just depending on it like a normal js module. That means we'll need to wait for a new nextjs release before the fix to enhanced-resolve makes it in, so I've temporarily disabled testing that example. |
|
Going to merge this to unblock testing examples in js-ipfs again, happy to make further PRs to address any review comments. |
The next ipfs release will be a dual ESM/CJS version which is presenting
some interesting challenges for all the different tools used here.
We also use the
ipfsmodule everywhere when we could be usingipfs-coreinstead - it's lighter and much quicker to install. Really we should only
use
ipfswhen we need the CLI and the HTTP RPC API, though I'm a littlewary of the potential confusion for new users having two options introduces.
Todo:
'next'dep versions with actual releases