When axios#4787 was implemented, the project was switched to `"type": "module"` and "./index.js" became an esm file instead of commonjs, however, the "main" entry in package.json still points to "index.js". As a result, consumers using this field may get unexpected behavior since the main field is supposed to be commonjs if the entry is provided.

Many consumers won't run into this as a practical problem (for example when just doing `const axios = require('axios').default` from inside of a cjs file in node) because the "exports" map takes precedence over the main/module fields, but tools that don't parse the object map when resolving still run into problems here.

The fix for this is to just point the "main" entry-point to the commonjs artifacts located at "./dist/node/index.cjs".

When axios#4787 was implemented, the project was switched to `"type": "module"` and "./index.js" became an esm file instead of commonjs, however, the "main" entry in package.json still points to "index.js". As a result, consumers using this field may get unexpected behavior since the main field is supposed to be commonjs if the entry is provided.

Many consumers won't run into this as a practical problem (for example when just doing `const axios = require('axios').default` from inside of a cjs file in node) because the "exports" map takes precedence over the main/module fields, but tools that don't parse the object map when resolving still run into problems here.

The fix for this is to just point the "main" entry-point to the commonjs artifacts located at "./dist/node/index.cjs".

When axios#4787 was implemented, the project was switched to `"type": "module"` and "./index.js" became an esm file instead of commonjs, however, the "main" entry in package.json still points to "index.js". As a result, consumers using this field may get unexpected behavior since the main field is supposed to be commonjs if the entry is provided.

Many consumers won't run into this as a practical problem (for example when just doing `const axios = require('axios').default` from inside of a cjs file in node) because the "exports" map takes precedence over the main/module fields, but tools that don't parse the object map when resolving still run into problems here.

The fix for this is to just point the "main" entry-point to the commonjs artifacts located at "./dist/node/index.cjs".

I also added a module entrypoint to improve compatability for the cases where the export map is not used (webpack 4 for example) since that would likely be reading the cjs "main" entrypoint now that main has switched back to cjs.

As grunt devDependencies were already remove in axios#4787, change the
grunt related CLI run, including `grunt build` and `grunt test` to
`npm run test` and `npm run build`.

Refs: axios#4787

…d and maxRedirects is set to 0

The axios request is left in an unsettled state (waits forever) when using compression
and maxRedirects is set to 0 and the request gets aborted after some chunks are sent.

The problem is that the response `abort` event is not being emitted and the request state
inside the `responseStream.on('error')` callback is `destroyed: true, aborted: false`.

I see that previoysly axios was checking `req.aborted` instead of `req.destroyed` inside
the `responseStream.on('error')` callback, but since node deprecated the `req.aborted`, it was
changed to `req.destroyed` in axios#4787.

We could change that back to `req.aborted`, but I think checking `rejected` would be
a better option, so we can be sure that we are catching all the errors
(in case there are some more weird cases).