0

After starting a standard ASP.Net 5 Web Application, and adding npm packages, VS2015 has stopped nesting them. Even with one simple package such as 'del', I see -

enter image description here

I'm sure it should be showing just the primary package, with its dependencies nested beneath it. VS is now doing this across all projects, whereas they used to be neatly nested. Adding two or three packages ends up with an enormous and unmanageable list of extraneous packages.

If I run npm list from the command prompt, the output indicates all the packages nested neatly below del. I've tried npm prune and npm cache clean but without success. NPM reports version 5.4.0 of node, and 3.5.4 of itself, if that's relevant.

I'd like to get it behaving as it should!

EDIT - It appears to only happen if you change the default Node.js to a more up-to-date version. The defaults on VS2015 Update 1 appear to be NPM 1.4.9, Node 0.10.31. Still doesn't help though. I suspect this is not going to be resolvable without an update to Visual Studio, but there might be a clever way around it.

Party Ark
  • 1,061
  • 9
  • 20

2 Answers2

2

This is by design, as the new version of node no longer nests NPM packages by default. The reason why this was changed is because the old design often caused MAX_PATH issues, where nested projects would create path lengths that easily passed the 256 character limit on Windows.

I understand that you like the nesting from a presentation standpoint, but from a reliability standpoint this is a huge improvement. NPM users on Windows hit this problem all the time.

Michael Braude
  • 6,913
  • 1
  • 22
  • 20
  • Please see my "answer" above/below. – Party Ark Jan 11 '16 at 23:44
  • I understand your point. It might be possible to override this behavior in a npm settings file. See https://docs.npmjs.com/cli/config for more info. – Michael Braude Jan 12 '16 at 01:26
  • Thanks for the pointer. I've reverted back to the npm2 branch and it's all working nicely. I've amended my answer, so hopefully it'll be useful. – Party Ark Jan 12 '16 at 09:57
  • 1
    One final thought - I do think this is a VS GUI issue. At the moment VS is just looking at the filesystem to infer the npm structure. That's not going to work going forward. But `npm list` _is_ able to infer a 'directory' structure - that's what VS should be looking to and replicating. Then the path to npm3 and above would be clear. And since `npm list` is available on all versions of npm, such a fix would not be breaking. – Party Ark Jan 12 '16 at 10:30
  • Thanks. I'll pass the feedback on to the asp.net team. – Michael Braude Jan 12 '16 at 16:36
1

EDIT - Here's the answer.

The core of this issue is that npm3 has decided to flatten the modules directory, primarily owing to issues with Windows applications using old APIs that don't support long file paths.

Long file paths doesn't seem to be an issue with VS. Since npm2 is still being actively maintained, you should use the npm2 branch if you want to avoid nightmare nesting.

However, updating node.js installs the latest npm3 branch. To bring your npm back to the 2 branch, you should run Powershell as administrator, and run

npm install -g npm@2.14.14

Restart VS. If you've already got a flattened directory, then open your node_modules folder and delete everything, then Restore Packages from the VS GUI. You should then get back to a workable structure.

(This is really a reply to Michael, but I need to post an image which I can't do in the comments.)

Thank you for clarifying the position. I hope you won't mind if I point out why I think this is a very problematic position.

First, the standard set of npm packages is the entirely reasonable "gulp": "3.8.11", "gulp-concat": "2.5.2", "gulp-cssmin": "0.1.7", "gulp-uglify": "1.2.0", "rimraf": "2.2.8"

Here's the resulting package list:

List of flattened npm packages

I think you can see straight away how that's pretty unworkable.

Second, it becomes impossible to uninstall a package.

Third, there is some nesting, but quite why and how is a bit of a mystery.

The corollary would be listing every ASP.Net package that's installed under DNX - there would be literally hundreds, and it would be similarly unworkable.

I don't fully understand the character limit issue, but it seems to me to be more a GUI issue. Thanks again.

superjos
  • 12,189
  • 6
  • 89
  • 134
Party Ark
  • 1,061
  • 9
  • 20