Potential POA for excluding fetch-blob from UMD builds

[drewdaemon]

Fetch-blob is a Node implementation of Blob. UMD builds are never run in a node environment. Therefore, excluding fetch-blob from UMD builds would both get rid of some tooling warnings (https://github.com/Esri/solution.js/issues/316) and slightly shrink our bundle size.

To do this, we could use the Rollup alias plugin to direct the fetch blob import to an empty module like so:

import alias from '@rollup/plugin-alias';

module.exports = {
  input: 'src/index.js',
  output: {
    dir: 'output',
    format: 'cjs'
  },
  plugins: [
    alias({
      entries: [
        { find: 'fetch-blob', replacement: './dummy-module' },
      ]
    })
  ]
};

This would allow the code to be none-the-wiser. The fetch-blob import would remain syntactically unchanged, only redirected to an empty module for UMD purposes.

[tomwayson]

I'm not sure this issue is isolated to creating UMD builds.

While working on #250 I created a test Ember app w/ the same Hub.js/rest-js dependencies as the Hub, and then added an application controller w/:

import { _checkStatusAndParseJson } from '@esri/hub-sites';
import { getItems } from '@esri/hub-search';

and when I run a build via ember s I get:

ERROR in ./node_modules/fetch-blob/index.js
Module not found: Error: Can't resolve 'stream' in '/Users/tom/test/tslib-test/node_modules/fetch-blob'

I'm not sure how the Hub ember app's build is even working right now.

[dbouwman]

Could we do something like what rest-request does here --> https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-request/src/utils/encode-form-data.ts#L22

if (typeof Blob !== "undefined") { ...work with Blob ...}

and for now, just throw in Node?

[tomwayson]

@drewctate I thought maybe ember-auto-import was bringing in the UMD builds in my test app, but I see this in the debug output:

  ember-auto-import:splitter output {
  "app": {
    "static": [
      {
        "specifier": "@esri/hub-search",
        "entrypoint": "/Users/tom/test/tslib-test/node_modules/@esri/hub-search/dist/esm/index.js",
        "importedBy": [
          {
            "package": "tslib-test",
            "path": "tslib-test/controllers/application.js",
            "isDynamic": false
          }
        ]
      },
      {
        "specifier": "@esri/hub-sites",
        "entrypoint": "/Users/tom/test/tslib-test/node_modules/@esri/hub-sites/dist/esm/index.js",
        "importedBy": [
          {
            "package": "tslib-test",
            "path": "tslib-test/controllers/application.js",
            "isDynamic": false
          }
        ]
      }
    ],
    "dynamic": []
  },
  "tests": {
    "static": [],
    "dynamic": []
  }
} +1ms

which indicates to me that it's bringing in the ESM builds.

[drewdaemon]

Here's another idea. We would create a package that returns either fetchBlob or blob depending on the target. This is exactly what the cross-blob lib does.

{
  "exports": {
      "browser": "./blob-browser.js",
      "default": "./fetch-blob.js"
    }
}

(ref: https://nodejs.org/api/esm.html)

[tomwayson]

Nice idea @drewctate

Can we just use cross-blob?