Nativescript: Can no longer use Axios

[rynop]

Environment
✔ Component nativescript has 6.0.3 version and is up to date.
✔ Component tns-core-modules has 6.0.7 version and is up to date.
✔ Component tns-android has 6.0.2 version and is up to date.
✔ Component tns-ios has 6.0.2 version and is up to date.

running on iOS emulator

Describe the bug

Axios thinks NS is a NodeJs environment, which causes this call stack and error:

Module not found: Error: Can't resolve 'net' in '/Users/ryan/projects/ns-binary-test/node_modules/debug/src'
 @ ../node_modules/debug/src/node.js 193:16-30
 @ ../node_modules/debug/src/index.js
 @ ../node_modules/follow-redirects/index.js
 @ ../node_modules/axios/lib/adapters/http.js
 @ ../node_modules/axios/lib/defaults.js
 @ ../node_modules/axios/lib/axios.js
 @ ../node_modules/axios/index.js

Obviously NS does not implement the net module. I know I've used Axios in NS in the past. After debugging I can't figure out what changed.

To Reproduce

1. tns create ns-axios-test --ng
2. Add import Axios from 'axios'; to item.service.ts
3. Add const axios = Axios.create(); to getItems()
4. tns run ios

Expected behavior

Axios should load and use XHR (XMLHttpRequest) adapter

Additional context

The Axios code that determines XHR (browser) vs http (NodeJS) module load can be found here

[NickIliev]

@rynop with NativeScript 6 we are using WebPack by default and with Webpack we have a process variable (see here)

I guess you could modify the posted Axios if/else check for the process so you could end up with XHR instead of entering the other condition.

[rynop]

@NickIliev thanks for helping me find that needle.

I'm personally fine with using a different HTTP client, however given axios is the most popular HTTP client, having every user modify its source locally/fork probably isn't practical.

@NickIliev do you know offhand why NS needs the process variable? With this ammunition I can see if the Axios team would be willing to change how the decision is made (ex: existence of an AXIOS_ADAPTER environment variable).

For others who may run across is issue, I tried forcing XHR but it is too late. Axios makes the decision at import time.

// force XHR
import xhrAdapter from 'axios/lib/adapters/xhr';
Axios.defaults.adapter = xhrAdapter;

[NathanaelA]

I'm actually the guilty party for getting the process: global.process added to the webpack configs.
By default initially webpack would hard code to undefine process, because of this issue:
https://github.com/NativeScript/nativescript-dev-webpack/pull/619

However, when we moved to everyone has to use webpack (i.e. NS 5.4/NS 6); we found plugins that were broken because they would actually use process in them. If process was undefined; they would then proceed to define process and add the polyfil of the parts of process that they needed to have defined so that the underlying node code would work fine...

Which then meant Webpack completely broke those plugins. By using process: global.process
we eliminated the issue, totally. That code needs to remain; otherwise you break existing plugins that have been around for a long time. However, if you find you are not using any of those plugins, you can easily change your own webpack config file to say "process: undefined" and that should allow your app to use Axios easily. But just remember their are plugins in the ecosystem that will totally fail if you do that, because they do setup process -- they still expect process to be valid....

[rynop]

Thanks @NathanaelA

After debugging some more, at runtime process IS undefined in NS. So the Axios lib at runtime is correctly identifying it is NOT a NodeJS env (and therefore is using XMLHttpRequest).

So what I've determined (and guessing you already know this) is my error in the original post is occurring during the webpack phase. My guess is webpack is just looking for require statements in the code its analyzing, not caring that in this case the require happens at runtime.

So is there any downside with an error in the webpack phase, if I'm OK with the error?

I'm getting an unknown error when doing an Axios POST. I figured it was due to this change, might not be now...

[NathanaelA]

Yep, if you don't have any plugins creating a process object then global.process will be undefined. :grinning:

A webpack build time error; normally won't cause any issues if it is something you aren't using in your app. (And in this case you aren't) Since it is just one of the node stock requires; you can easily add it to the webpack externals; and then webpack wills stop complaining about it. :grinning: Your are correct webpack finds ALL requires, and tries to resolve them...

Now as to your actual error, I haven't ever used Axios; so unfortunately I can't really help on that aspect... Good luck, in figuring it out!

[rynop]

Thanks. I'm going to close this as it is not a real problem with Axios, nor using it in NS. It is just a Webpack nuance, that can be safely ignored. Hopefully this helps someone else save time when they run across the same err.

I was able to track down my error, and its not an Axios error, just bubbles up through the Axios call stack.

[belvederef]

Shoutout to everybody. I could not correctly use axios until I imported the package via

import axios from 'axios/dist/axios'

this also solves the Module not found: Error: Can't resolve 'net' in... error.

When importing the package normally my requests failed returning the error

Error in v-on handler (Promise/async): "Error: Request failed with status code null"

[tuliodiaz]

Since @rynop comment about the right require will be executed at runtime. This solve my problem

npm install net --save-dev