search

expressjs / compression

Node.js compression middleware
MIT License
2.77k stars 241 forks source link

npm tarbal URL is `http` #140

Closed XhmikosR closed 6 years ago

XhmikosR commented 6 years ago

So, I'm trying to get to the bottom of this.

In my case 2 specific packages change my package-lock.json links to registry.npmjs.org to http. One of them is compression.

Whoever makes the releases can you check what the value of npm config get registry is on their machine?

Thanks!

dougwilson commented 6 years ago 
$ npm config get registry
https://registry.npmjs.org/
XhmikosR commented 6 years ago

Very weird. We'll see if we can find the root cause.

Thanks for confirming!

dougwilson commented 6 years ago

No problem! I don't think my registry value really is stored anywhere. Perhaps try completely clearing all the npm cache locally npm cache clean --force and see if that helps? Not sure if the cache remembers it getting downloaded from http at some point on your machine, idk. Just guessing here. The npm folks could probably say exactly why npm is putting http: for the dep in your shrinkwrap, though.

XhmikosR commented 6 years ago

Yup, I have already done all this. This issue isn't new, it happens for some months now. But it only happens for specific packages for me, that's why I thought I'd ask.

kevinburke commented 6 years ago

Interesting... check the tarball URL, this is using NPM 6 on a Mac. Is that something that you set when you upload tarballs?

$ npm info compression

compression@1.7.2 | MIT | deps: 7 | versions: 34
Node.js compression middleware
https://github.com/expressjs/compression#readme

dist
.tarball http://registry.npmjs.org/compression/-/compression-1.7.2.tgz
.shasum: aaffbcd6aaf854b44ebb280353d5ad1651f59a69
.unpackedSize: 22.6 kB

dependencies:
accepts: ~1.3.4       bytes: 3.0.0          compressible: ~2.0.13 debug: 2.6.9          on-headers: ~1.0.1    safe-buffer: 5.1.1    vary: ~1.1.2

maintainers:
- dougwilson <doug@somethingdoug.com>

dist-tags:
latest: 1.7.2

published 3 months ago by dougwilson <doug@somethingdoug.com>
dougwilson commented 6 years ago

All I do is type "npm publish" and then enter my 2FA code at the prompt.

kevinburke commented 6 years ago

OK - This is a dumb question, but you use a recent-ish version of NPM when you run that command, right?

dougwilson commented 6 years ago

Yes, 2FA code prompt support was not added until npm 5.5.1. Now, which specific version I used when I published 3 months ago I cannot know for certain, but I keep it as up-to-date as possible, so it would be a reasonable version for the time of the publish date.

kevinburke commented 6 years ago

Looking here: https://registry.npmjs.com/compression

The 1.7.1 release has https://registry.npmjs.com for the tarball URL and the 1.7.2 release uses http://registry.npmjs.com for the tarball URL. Did you/the same person prepare both releases, and did you/they use the same procedure for each release?

This is weird and it's almost certainly not a problem on your end, but thanks for writing back, as this should help narrow down the issue.

dougwilson commented 6 years ago

Yea, I've been the only one publishing this particular module and I always do the publishing from the same machine (git development may be on different machines, though). This is because my registry token is only on a single machine for security reasons. That machine is where I ran https://github.com/expressjs/compression/issues/140#issuecomment-392128763 on and it doesn't change too often since I just use it for publishing (it's a virtual machine).

kevinburke commented 6 years ago

OK, thanks! This has been really helpful.

dougwilson commented 6 years ago

No problem. There are probably some changes I can publish, so I will publish a new version if there's any dep update pending here and we'll also be able to see if that resolves this issue for some reason. I also have some projects with package-lock.json files and compression 1.7.2 does have a https link, though I see the same behavior with other modules: running npm install changes some of the URLs to http from https even though there are no version changes in any way. I've seen the issue off-and on and sometimes seems to change which modules are getting downgraded ... ?

kevinburke commented 6 years ago

I've attempted to follow up with the NPM team, I'll let you know if/when I have more information.

dougwilson commented 6 years ago

Awesome. It would be weird if the actual publisher affects this somehow, but you never know. Definitely would be useful to know whatever the root cause is found to be, though, because it's something else to keep in mind on going!

XhmikosR commented 6 years ago

BTW, the behavior is the same with npm 6.1.0 as it was with npm 5.6.0.

So weird issue :/