Hello Julien, I've filed this as PG-1147 and a fix should be coming in the next version of ProGet.

Thanks Ben that did the trick :-)

Hello Ben, thanks for help. I can confirm that node.js v 6.11.4 with slash at the end of URL works ;)

You will need to open both ports; the npm api uses both HTTP and HTTPS.

I don't believe the NPM protocol allows for anonymous pushes. You could certainly have your CI put it in a drop folder however, which the ProGet would pick-up.

The best work-around for this is to create as secondary IIS site that points to the same root, and then configure no Windows Auth on that site. You will need to have two proget urls; one with WIA and one without. Unfortunately there is no other workaround, as NPM simply doesn'ts upport it, and IIS doesn't support having some parts of the site use WIA, and others not.

Tagging would indeed be the solution, now it's clear how we should have been working. Thanks for the fast feedback!

Thanks, that fixed it.

Hello Robert, Thanks for the bug report! I've filed this as PG-1047. NPM feeds were showing the download count as the total for all NPM packages, not just the ones associated with that feed.

The npm search command has been broken in npm for some time, as it downloads the entire package index and searches it locally. Due to the size of the index on npmjs.org, this stopped working for a lot of people due to npm OutOfMemory errors and various other issues. Because of this, they deprecated this form of searching in the npm client in favor of a new search API, but it seems that only npm 4+ actually uses the new API. Indexing all of npmjs.org also caused a lot of problems for our users due to the sheer amount of data involved, so we dropped indexing of any registry that supports the search API. Local packages are still returned in the /-/all endpoint, since this doesn't require the same server overhead, which is why you are still seeing those packages. Basically, you may want to try the new npm client, or just stick to searching on the web for now.

Sorry for the confusion... I think those should be listed as "internal only" methods, and not on the API page. Anyway, the Native API can only be used for metadata. So you won't be able to use it in this manner.

Ugh. Apparently what I meant to say was there were no changes, except for that one that causes this exact problem with npm feeds :/ Thanks for doublechecking me, looks like I needed it. (Apparently this is a very simple fix that had already been corrected by a dev for the upcoming 4.7.10, due for release today). For your reference, this is now logged as PG-1014

Hello Michael, NPM feeds don't currently support an API key, but you can share a single ProGet user between all of the users who need to upload to the feed to simulate the same thing. The Publish Packages task group on the NPM feed is all you need to upload a package. If you want to replace an already-uploaded package, you need the Overwrite Package task, which is available on the Administer and Manage Feed task groups by default, but you can create a new task group with just Overwrite Package on the Customize Tasks page (/administration/security/customize-tasks).

There's a bug we haven't been able to figure out where the Linux version of ProGet doesn't respond to requests for URLs with colons in them.

If you are using IIS, you'll need to make sure that the ProGet AppPool is set to use Integrated Pipeline mode. If hosting with the integrated web server, it should just work. You may also need to enable always-auth for npm to force basic authentication.

Please upgrade to the latest version of ProGet; 4.3.1 is outdated.

This seems to be fixed as of the Docker image containing ProGet Version 4.7.14. The Docker image hash is: b7a3d6595c21d34997b4cbe6da9187801f410f17bff8e84228711bf29396a6ab pulled on 9/6/2017

Ok, I noticed that in your log, npm isn't authenticating. Is the anonymous user allowed to access the feed in ProGet?

Alana, I think it maybe a UTC boom... I will try today to "fiddler" it.