Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 6 commits into from

Conversation

@NathanaelA
Copy link
Contributor

NathanaelA commented Jul 26, 2019

PR Checklist

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
image

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

@cla-bot cla-bot bot added the cla: yes label Jul 26, 2019
@project-bot project-bot bot added this to Pull Request in CLI Team Jul 26, 2019
NathanaelA added 5 commits Jul 26, 2019
@NathanaelA

This comment has been minimized.

Copy link
Contributor Author

NathanaelA commented Jul 27, 2019

@rosen-vladimirov - Any chance this can be merged into 6.03 (or whatever the very next release is)?

@@ -36,6 +38,20 @@ interface ITestCase extends ITestSetup {
expectedArgs: any[];
}

function createPacoteOptions(source: Object): Object {
const options: { [index: string]: any } = {};
npmconfig.read().forEach((value: any, key: string) => {

This comment has been minimized.

Copy link
@DimitarTachev

DimitarTachev Jul 30, 2019

Contributor

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.

This comment has been minimized.

Copy link
@NathanaelA

NathanaelA Jul 30, 2019

Author Contributor

You can't because the actual Pacote driver will be loading the npm config; which it passes back and won't match your hard coded one. So we have to pass in anything we expect it to get by itself. :-)

This comment has been minimized.

Copy link
@NathanaelA

NathanaelA Jul 30, 2019

Author Contributor

Lets try this a third time. 😀
The Pacote Driver itself will now load the npm configuration. If we don't have a copy of the npm configuration in the test; then what is returned (and compared) doesn't match. So I load it here; so that they match. However, if you are thinking we need to send in an empty set of options and have a second object that has what we expect it to be, that is something I can do...

This comment has been minimized.

Copy link
@DimitarTachev

DimitarTachev Jul 31, 2019

Contributor

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?

This comment has been minimized.

Copy link
@NathanaelA

NathanaelA Aug 1, 2019

Author Contributor

Yarn will pull the same .npmrc file for server information. So we should be safe here -- the main values for where servers live and the authentication to talk with them will be pulled from the ~.npmrc file.

As for moving things into a service and mocking it -- you totally lost me. Pretend I'm 2yo; and let me know exactly want you need and I'll get it done. 😀 I'll be rebasing this onto Release, and we can move the discussing over their. 😀

This comment has been minimized.

Copy link
@NathanaelA

NathanaelA Aug 1, 2019

Author Contributor

#4919 is the PR against Release

@DimitarTachev

This comment has been minimized.

Copy link
Contributor

DimitarTachev commented Jul 30, 2019

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 nativescript@6.0.3.

@NathanaelA

This comment has been minimized.

Copy link
Contributor Author

NathanaelA commented Jul 30, 2019

@DimitarTachev - Are you just wanting me to just move this over to release, or do you still want the test issue changed up a bit? Trying to understand exactly what my next steps on this needs to be. 😀

@DimitarTachev

This comment has been minimized.

Copy link
Contributor

DimitarTachev commented Jul 31, 2019

@NathanaelA,

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

@rosen-vladimirov

This comment has been minimized.

Copy link
Contributor

rosen-vladimirov commented Aug 29, 2019

Closing this PR in favor of #4992

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
CLI Team
  
Pull Request
3 participants
You can’t perform that action at this time.