So, make sure you take a backup of your scripts before modifying them.
Of course, here be dragons: I have no idea how stable this will be with updates to VS, and/or how badly you may be crippling features if you mess this up. I installed node (which includes npm), then updated npm to the latest version (thanks to this module) and updated my npm.cmd to the Files (x86)\nodejs\node.exe” “C:\Program Files (x86)\nodejs\node_modules\npm\bin\npm-cli.js” % With that knowledge, we can simply update the call that is proxied through to our current version. So, when VS issues an “npm install”, this command kicks in, runs npm via node and passes “install” as the command to npm. So, the command is running node (which is an exe), passing in the VS version of npm, and pushing into it the rest of the parameters that were passed along. It’s a very hard-to-read version of “.” in most other notations. So, basically, “start from where you’re running”. The %~dp0 is the old command line way of bringing the current drive letter (the d in the command), the path (the letter p here) and the current directory of the executing script (represented by 0) into context. For me, they were located in the following directory:Ĭ:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Externalįor example, here the entire contents of “%~dp0\npm\node_modules\npm\bin\npm-cli.js” % These are pretty straightforward, once you find them. So, back to the dicing! Hacking up the VS Tooling Proxies The latest major version of npm – version 3.0.x and above – creates a flat store of packages (very similar to what we know in NuGet) and only pulls one copy of each required version of each required package. Except, of course, if one of those packages contained more dependencies, then we were into the recursive bits of package resolution and very deep paths, ultimately toppling a lot of Windows tooling. Older versions of npm resolved package dependencies by pulling in a package, creating a node_modules folder inside of it, then putting all the packages in there. For me, I was trying to share the files on OneDrive and hit 255 characters pretty quickly. Nested node_modules folders buried 19 levels deep is no fun when you hit the max path length.
Wait a minute! Why are we doing this?įor me the primary motivator was the path length limitations in Windows. Use the built-in external tool path editor to slip your updated versions in.Hack the tooling proxies used by Visual Studio.Wait for VS 2015 to upgrade the tooling and ship an update.If you are wanting to take advantage of newer versions of these tools, you have three options: Typically, you’d have to wait for newer versions of VS to ship if you want them updated. Visual Studio 2015 ( download here) ships with it’s own version of several external tools, such as grunt, node and npm.
0 kommentar(er)
