Travis-ci: added support for ppc64le & Removed unsupported versions for ppc64le

[dthadi3]

Hi,

I had added ppc64le(Linux on Power) architecture & Removed unsupported versions for ppc64le support on Travis-CI in the PR and looks like its been successfully added.

Reason behind running tests on ppc64le: This package is included in the ppc64le versions of RHEL and Ubuntu - this allows the top of tree to be tested continuously as it is for Intel, making it easier to catch any possible regressions on ppc64le before the distros begin their clones and builds. This reduces the work in integrating this package into future versions of RHEL/Ubuntu.

Regards,
Devendra

[ljharb]

Nothing about this package (or any pure-JS package that doesn't touch the filesystem) can vary based on architecture, so testing in other architectures is not valuable.

[dthadi3]

Sorry for the late reply @ljharb
I can see like package.json file lists the dependencies and that the build or testing can fail due to any of those as well and unless we actually run the builds we can probably never be 100% sure that it won't.

In General, we have seen that a lot of times node.js packages fail because of missing dependencies or dependencies on native code and such, in my automation that builds and validates a lot of these, we have found that to be the case for around ~20% of the packages. Ensuring that they build and all the unit tests pass on the target architecture and doing that via a CI on an on-going basis will ensure that we have complete coverage.

[goto-bus-stop]

we have seen that a lot of times node.js packages fail because of (..) dependencies on native code and such,

That makes a bit more sense. But this package targets browser environments primarily, and actually runs tests in various browsers too. Browsers don't support any native modules so we are already prevented from accidentally introducing such a dependency.

[dthadi3]

@goto-bus-stop We appreciate for the additional information.

[ljharb]

Either way, running tests in other architectures is valuable for those native deps - if there's N native deps out there, why would it make sense to add stuff to CI for the N * M consumers of them, rather than just the N deps themselves?