[Package Request] IPFS

[5310]

Apologies for bringing up an issue about a package with a terrifyingly huge dependency graph, but I can't import IPFS over Skypack.

Simply importing the package fails as somewhere in the process a require invocation slips through.

import * as pkg from 'https://cdn.skypack.dev/ipfs';
console.log('ipfs loaded:', pkg);

Throws:

Uncaught ReferenceError: require is not defined
    at env.js:2

Where env.js is as follows when inspected in the browser, (it's small enough):

'use strict'
const isElectron = require('is-electron')

const IS_ENV_WITH_DOM = typeof window === 'object' && typeof document === 'object' && document.nodeType === 9
const IS_ELECTRON = isElectron()
const IS_BROWSER = IS_ENV_WITH_DOM && !IS_ELECTRON
const IS_ELECTRON_MAIN = IS_ELECTRON && !IS_ENV_WITH_DOM
const IS_ELECTRON_RENDERER = IS_ELECTRON && IS_ENV_WITH_DOM
const IS_NODE = typeof require === 'function' && typeof process !== 'undefined' && typeof process.release !== 'undefined' && process.release.name === 'node' && !IS_ELECTRON
// eslint-disable-next-line no-undef
const IS_WEBWORKER = typeof importScripts === 'function' && typeof self !== 'undefined' && typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope
const IS_TEST = typeof process !== 'undefined' && typeof process.env !== 'undefined' && process.env.NODE_ENV === 'test'

module.exports = {
  isTest: IS_TEST,
  isElectron: IS_ELECTRON,
  isElectronMain: IS_ELECTRON_MAIN,
  isElectronRenderer: IS_ELECTRON_RENDERER,
  isNode: IS_NODE,
  /**
   * Detects browser main thread  **NOT** web worker or service worker
   */
  isBrowser: IS_BROWSER,
  isWebWorker: IS_WEBWORKER,
  isEnvWithDom: IS_ENV_WITH_DOM
}


export default null;
export const __esModule = true;

[FredKSchott]

Hey! Thanks for filing. It looks like IPFS is importing ipfs-utils/src/env, which is a Common.js file (not ESM, not loadable directly in the browser) https://github.com/ipfs/js-ipfs-utils/blob/master/src/env.js

We have a longer-term project to up-convert these individual files from CJS to ESM (the same way we upconvert CJS packages to ESM). That would hopefully fix this issue.

you could also reach out to ipfs & see if they would import these different utils from the ipfs-utils package directly, instead of ipfs-utils/src/*.

[drwpow]

Update: we released a big update to the CDN this week, and it looks like we were able to solve some of the CommonJS problems, but the package failed to build. It seems that some of its dependencies like libp2p couldn’t be built properly.

I’ll investigate a little more, but it may be unlikely that we can get it working easily as there’s a lot of Node-specific code to all of these dependencies. We’re handling CJS a lot better, and we can handle a few common Node.js polyfills, but at a certain extent we won’t be able to run Node.js APIs in the browser (and currently a lot of these will surface as build errors or the package failing to load)

[5310]

I was going to try importing it again seeing issue 40 get closed, but you got here immediately!

Thank you for continuing to investigate it. IPFS works fine in a script tag using the bundle they produce on their end which I assume includes all sorts of magic needed to do so. But the NPM package with its huge dependency tree is still just made for Webpack I guess.

[drwpow]

Just gave it another try after another CDN update and I’m afraid that ipfs is still only shipping Node.js code (to be clear—Skypack can upconvert a lot! But this is beyond its limits as this package expects a Node runtime). If ipfs ships ESM we can build it just fine, but for now, please use the provided bundle as you suggested:

https://cdn.skypack.dev/-/ipfs/dist/index.min.js

[FredKSchott]

@drwpow small note, that URL should be: https://cdn.skypack.dev/ipfs/dist/index.min.js

[snickell]

I believe the relevant issue on the IPFS side is: ipfs/js-ipfs#951

It might (or might not) help them if @drwpow or @FredKSchott dropped a line there what they might need to do to have a skypack build succeed.