Npm scoped packages - String is not a valid semantic version error

[Guest]

No, we haven't had scoped npm packages working before. Un-scoped npm packages work fine though. We have been using ProGet Enterprise for about 6 months for nuget packages and only recently started using it for npm packages.

I'm seeing exactly the same problem as these two support questions:
http://inedo.com/support/questions/3696 and http://inedo.com/support/questions/4680

Those support questions say this issue was fixed in ProGet 4.0.11, however we've tried this on versions 4.5.2 and 4.5.3 and still get the same issue. We're using node 6.7.0 and npm 3.10.6 on the client side. We have ProGet hosted on IIS 8, Windows Server 2012 R2.

[Guest]

Just some further information on reproducing this. We are just using a simple package.json to test with a scoped package, e.g.

{
"version": "1.0.0",
"name": "proget.test",
"private": true,
"dependencies": {
"@angular/core": "^2.1.0"
}
}

And we are running the npm install command, pointing the registry to our ProGet server, e.g.
npm install --registry http://cap-pkg.coretexa.local:8080/npm/C3-NPM

When we switch the package.json to only include un-scoped packages then it works fine, e.g.

{
"version": "1.0.0",
"name": "proget.test",
"private": true,
"dependencies": {
"moment": "2.17.0"
}
}

This seems to indicate that the connector setup is working correctly and ProGet is only returning the "String is not a valid semantic version" error when retrieving scoped packages.

[Guest]

Were you able to get this working? I seem to get the same issue with ProGet 4.6.5 (and types/fs-extra package)

[Guest]

No, I haven't been able to get scoped packages working. I'm on 4.6.3 now and still having the same issue. I've had to put in a workaround to go directly against www.npmjs.com for all npm packages, which is a shame because we really want all types of packages to go through Proget. Inedo support, any idea on what is causing this?

[Guest]

We're still researching it; there were some changes in 4.6 to the HTTP Handling, but it seems to have some issues w/ some IIS configurations (or perhaps, libraries used by IIS? patch versions of .net? not sure yet)...

The underlying problem is the %2f as part of the path. This is simply not a common scenario, and is almost always accidental, which is why the underlying libraries (proxy servers sometimes, etc) automatically convert it to a "/" when passing it to the next thing in the pipeline.

[Guest]

Same problem here. We can't install any scoped package. Also when we open an deployed own scoped package, an unhandled error occurred:

Invalid npm package id.
with the following stacktrace:
[FormatException: Invalid npm package id.]
Inedo.ProGet.WebApplication.UnifiedFeedBrowsing.Feeds.NpmFeedDataFactory.ParsePackageIdentifier(String urlPackageVersionIdentifier) +518
Inedo.ProGet.WebApplication.Pages.Packages.PackageVersionPage.CreateChildControls() +173
Inedo.ProGet.WebApplication.Pages.<InitializeAsync>d__2.MoveNext() +281
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Inedo.ProGet.WebApplication.Pages.Packages.<InitializeAsync>d__18.MoveNext() +950
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Inedo.Web.PageFree.<ProcessRequestAsync>d__48.MoveNext() +380
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +98
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +606
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

It's very urgently needed to get this running;)

[Guest]

Unfortunately, at this point, we're unable to reproduce this at all, under any configurations of Windows. Upon installing a trace on the incoming requests to ProGet, the underlying problem is that the request being made to ProGet is incorrect, it has a / in the url instead of %2f.

So, we believe a proxy server or intermediate network appliance is replacing %2f with /. We have seen some reverse proxies do this already. It is highly unusual for a path to contain a %2f, so this is probably why such a problem/bug in the intermediate hardware would go unnoticed.

[Guest]

Hi Alana,

When you say "the request being made to ProGet is incorrect, it has a / in the url instead of %2f", we have tried making direct requests to ProGet using Postman with both escaped and non-escaped paths and we still get the same error, i.e:

http://cap-pkg.coretexa.local:8080/npm/C3-NPM/@angular%2Fcore
http://cap-pkg.coretexa.local:8080/npm/C3-NPM/@angular/core

both produce the "String is not a valid semantic version" error.

We don't get the error when we try the same thing using a non-scoped npm package path, i.e.

http://cap-pkg.coretexa.local:8080/npm/C3-NPM/moment

Also, when you say "it is highly unusual for a path to contain a %2f", every npm scoped package will contain this as that is the format for a scoped package.
https://docs.npmjs.com/getting-started/scoped-packages

Scoped npm packages are becoming increasingly more common so it would be great to have a solution to this.

Regards,
David

[Guest]

Hi,

our case is fixed by adding the following configuration to the Web.config

<add key="aspnet:UseLegacyRequestUrlGeneration" value="true" />
Problem was the decoded @ in the url from the schöpfe package name.

[Guest]

Thanks very much Jean-Pierre,

That solved my problem.

Regards,
David

[Guest]

Thanks very much Jean-Pierre, this solved also my case.

[Guest]

Wow, great find... so, we will update the web.config that we ship with to contain this!

[Guest]

Your Welcome;)
We decompiled the code and debugged it to solve the problem. It took us the whole day:(
=> Alana, perhaps you could think about some logging, this would help us a lot;)

[Guest]

I found this thread after experiencing a similar issue. I was seeing the "string is not a valid semantic version error" from Proget when npm would try to install scoped packages, but only when the npm install was automatically triggered inside Visual Studio by a change to the package.json. We already had the latest version of Proget with the change to the web.config and installs worked fine when running from command line.

Problem turned out to be the fact that Visual Studio 2015 had installed it's own copy of the npm.cmd as an external web tool. This was an older version than the one I had installed globally, but the order of external web tool locations in Visual Studio had the path to the older version listed before my system path. Making system path take precedence solved the issue.

Just thought I'd post this here in case anyone else with a similar issue stumbles across this thread like I did.