fix(http): use explicit import instead of TextEncoder global;

[DigitalBrainJS]

TextEncoder class imported explicitly for node.js older than v11

Closes #5529;

[wkeese]

Hmm, this is failing for me on Chrome, Safari, and Firefox. Global TextEncoder is defined but the TextEncoder from

import { TextEncoder } from "util";

is undefined

[DigitalBrainJS]

TextEncoder class is only used in the Axios http adapter, which runs on the server side, not in the browser.

import { TextEncoder } from "util";

is platform-specific import for Node;

[wkeese]

Not quite... I understand that HttpAdapter is meant for Node. But the problem is that package.js directs us to use axios/index.js, for both the browser and Node. And when I create my own rollup using index.js, I get:

...
import require$$1$1, { TextEncoder } from 'util';
...
const textEncoder = new TextEncoder();

Both those statements are top level, not inside a function.

Now perhaps textEncoder (the instantiated TextEncoder) is never used on the browser, but it doesn't matter because I've already gotten a null pointer exception.

Somehow you've removed TextEncoder completely from dist/browser/axios.cjs. It's not just ESM module tree shaking, Rollup also somehow knows that this variable is false:

const isHttpAdapterSupported = typeof process !== 'undefined' && utils.kindOf(process) === 'process';

I'm curious how that works but in any case it doesn't help me because I'm not using dist/browser/axios.cjs and also because my own rollup is meant to work on both Node and the browser.

I have a similar problem with another recent change, even though zlib isn't "used" on the browser, this (top level not inside a function) code still tries to execute and gets a null pointer exception:

const zlibOptions = {
  flush: zlib.constants.Z_SYNC_FLUSH,
  finishFlush: zlib.constants.Z_SYNC_FLUSH
};

[DigitalBrainJS]

But the problem is that package.js directs us to use axios/index.js, for both the browser and Node.

It simply means that you misconfigured your build tool and it builds a node.js version of your package dependencies tree.

axios/rollup.config.js

Line 33 in 2e70cec

resolve({browser}),

Somehow you've removed TextEncoder completely from dist/browser/axios.cjs.

Well there's no magic here- that is just a well-known conditional export/import and their old prototype - browser field in package.json

[wkeese]

It simply means that you misconfigured your build tool and it builds a node.js version of your package dependencies tree.

No, I didn't, as I said above my own rollup is meant to work on both Node and the browser.

Well there's no magic here- that is just a well-known conditional export/import and their old prototype - browser field in package.json

OK, that's a neat trick but it doesn't help me because my own rollup is meant to work on both Node and the browser. If I do something like that, it will fix the browser but break node.

[DigitalBrainJS]

Your own rollup [config] should respect packages' conditional exports and have multiple entry points to make your app/lib multiplatform. This is how isomorphic npm packages work when the runtime environment does not allow to achieve package isomorphism.

[wkeese]

I thought you would say something like that. I'll just point out that Axios allowed consumers to have a single (multi-platform) build until version 1.2.1.

[DigitalBrainJS]

I'll just point out that Axios allowed consumers to have a single (multi-platform) build until version 1.2.1.

I really hope our consumers don't do that although this could explain why there are some people on the Internet who think that Axios weighs 2 MB :)
This was never possible unless you packaged all the native node modules with something like browserify in a huge bundle for the client, which is absurd since only a few percent of the code will be client-side related. But if we consider this acceptable, then nothing has changed since version 1.2.1 - just another import of the native node module has been added, exactly the same as all the others - http, zlib, stream, etc. This was never the intended ability, so it's not an Axios issue whether the bundler has an actual shim for the native node module import or not.

[wkeese]

I really hope our consumers don't do that although this could explain why there are some people on the Internet who think that Axios weighs 2 MB :)
This was never possible unless you packaged all the native node modules with something like browserify in a huge bundle for the client, which is absurd since only a few percent of the code will be client-side related.

Oh, you're almost right, it turns out Webpack uses node-libs-browser which pulls in shim libraries like stream-http, http-browserify, and zlib-browserify.

So yes, maybe Axios seems big to other people because they are pulling in those shim libraries.

I wasn't expecting any shim libraries to be involved because I'm used to code that dynamically checks for what's supported/available, something along the lines of:

if (typeof XMLHTTPRequest === "function") {
   ...
} else {
   const http = await import("http");
   ...
}

(That kind of code also allows for separate browser and node builds, but the penalty for having a single build is much less.)

But if we consider this acceptable, then nothing has changed since version 1.2.1

Nothing changed in a hypothetical world where all Node JS imports are shimmed and the shims works exactly as the real imports. What I meant is that, in reality, Webpack builds used to work, but now they don't.

You can of course say that it's not an Axios issue, and that you never intended to support this kind of build.

But the first thing that changed was that 1.2.1 introduced references to zlib.constants which work with Node but not with the shim:

const zlibOptions = {
  flush: zlib.constants.Z_SYNC_FLUSH,
  finishFlush: zlib.constants.Z_SYNC_FLUSH
};

(For some reason the shim defines zlib.Z_SYNC_FLUSH not zlib.constants.Z_SYNC_FLUSH.)

The second thing that changed (in this commit) is that you import { TextEncoder } from "util" instead of accessing it as a global. On browsers, the global works but the import doesn't, because Webpack isn't shimming that import.