fix(npm/pacote): allow tns to be able to use npm configuration properly

[NathanaelA]

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/nativescript-cli/blob/master/CONTRIBUTING.md#contribute-to-the-code-base
• Tests for the changes are included.

What is the current behavior?

If you have a npm registry that is not hosted by npm, the TNS cli will fail to install npm modules.
Doing a npm i --save @proplugins/blah will work 100% properly.
Doing a tns plugins add @proplugins/blah will partially work. It actually downloads the package (because it apparently uses npm under the hood and pulls the file and unpacks it, yay!).
So node_modules/@proplugins/blah is unpacked and exists on the drive.

However, apparently the tns cli uses pacote to verify the existence of the registry entry, BEFORE it adds it to the package.json file. Which of course because it is a older verison of pacote and does not read the npm configuration -- it has NO idea how to resolve @scoped to the private server. So tns then fails and so then tns throws

As you can see from the image; npm actually found the package and installed it; but TNS failed and either rolls back the package.json change, or doesn't commit the package.json change.

What is the new behavior?

Upgraded to latest pacote library; and added ability to read npm configuration files (using the official libnpmconfig, which is then passed into pacote; so of course it now works properly. :-)

BREAKING CHANGES:
None

[DimitarTachev]

Use a hardcoded config obj here instead of reading the real config from the file system and applying the same business logic in the unit tests.

[DimitarTachev]

Thanks for the details. As far as I understand, the problem is caused by libnpmconfig which is directly used in the Pacote service. In this way, we cannot inject a Stub returning a hardcoded value in the unit tests. If you refactor this part and extract the npmconfig related logic into a service, you will be able to mock it in the unit tests and avoid slow disk operations there. Also, have you checked this feature with yarn? Are they using the same config file?

[DimitarTachev]

Hi @NathanaelA,

Thanks for reporting and handling this!

It looks OK for a patch release as it's really a bug fix, you just have to rebase the PR on our release branch as the master branch will be released in 6.1.0.

We will run some tests after you rebase the changes on release and if everything is OK, we will include it in [email protected].

[DimitarTachev]

@NathanaelA,

Just rebase it on release and we will run the required tests on the updated PR.

[rosen-vladimirov]

Closing this PR in favor of #4992