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: set strictSSL on custom downloads from NPM config. Fixes #211 #212

Merged
merged 2 commits into from
Mar 15, 2020

Conversation

mefellows
Copy link
Member

Uses libnpmconfig to cascade through the various npm config layers and set the property on the download object.

Didn't like exporting the function in order to test it, but I needed a few tests around it at the time. Perhaps they can go now?

@mefellows mefellows requested a review from TimothyJones March 6, 2020 03:06
@@ -4,7 +4,7 @@
import * as fs from 'fs';
import * as path from 'path';
import * as chai from 'chai';
import { BinaryEntry, Config } from './install';
import { BinaryEntry, Config, useStrictSSL } from './install';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

useStrictSSL doesn't exist any more in this PR, I think? It's certainly not used in this file.

I tend to think that exporting things only for testing implies that the module cut points aren't right yet. Last time I was looking at modifying install.ts, I was thinking about refactoring it out to separate the different concerns. I didn't, because it was going to be substantial work that would be hard to test.

Pragmatically, I liked this change more when it had the tests, and I would like it even more if the config parts of install.ts were extracted to their own module. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh crap, yes I did remove that in the end. I'm surprised something didn't get upset about it (or maybe it did).

I tend to think that exporting things only for testing implies that the module cut points aren't right yet.

Agree (and hence my initial concern), but for a minor fix didn't want to refactor either! But also wanted tests.

To be honest, and this is definitely outside the scope of this, but the whole

  1. Have to npm t before npm i is a bit strange
  2. Have to npm t before npm run release (which also runs t anyway)

is a bit strange, and counter intuitive. I should be able to pull repo, npm it and be set 👌. I got tripped by this on the last release with the "checksum invalid" issue, only to realise that I needed to re-run all of the tests (which bring down all of the OS specific binaries).

I don't want all of this of course to get in the way of fixing a bug, so perhaps we create an issue, mark it as "help wanted" / "good first issue"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I've fixed that broken import by the way)

@mefellows mefellows force-pushed the fix/211_allow-strict-ssl-in-install branch from f8e2b51 to ae36609 Compare March 10, 2020 09:57
@TimothyJones TimothyJones merged commit 2ddbeae into master Mar 15, 2020
@TimothyJones TimothyJones deleted the fix/211_allow-strict-ssl-in-install branch August 28, 2020 02:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants