I am trying to publish a pure client project - that is - plain html/js/css files, that during dev being managed by nodejs.
Node creates a very deep path (longer than 260 chars) - inside node_modules/...
Although I have excluded node_modules completly:
<ExcludeFoldersFromDeployment>test;node_modules</ExcludeFoldersFromDeployment>
It still throws an exception when I try publishing:
Error 1 The "CollectFilesinFolder" task failed unexpectedly.
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified
file name must be less than 260 characters, and the directory name must be less than 248 characters.
at System.IO.PathHelper.GetFullPathName()
I know it is specifically the node_modules, because manually removing it solves the issue.
Other then that, excluding works fine (the 'test' folder is being excluded).
How do I keep these files from being considered for the publish?
I solved this by installing some (if not all) of the dependecies globally:
npm install -g package
and then installing into the project using
npm install --link
The result is that NPM will create shortcuts to your globally installed packages instead of copying them, and it seems that msbuild does not try to follow these links.
You can simply hide the folder, i.e. set the hidden attribute, and aspnet_compiler will skip it avoiding this error to happen.
I've tested this with TypeScript typings, and grunt tasks, and they work perfectly with this folder hidden. Of course, npm install and npm update also work fine.
If you hide this in the command line or using a script, use this command
attrib +H "path\to\folder\to\hide"
You can also use this command in a msbuild task, as explained in this answer to How do you handle excluded files with aspnet_compiler?
Related
This feels like an embarrassing question to ask but having recently published a Node package to the NPM registry, I now find it doesn't work.
The issue seems to be that my main file, ./src/index.js, isn't being included in the global install.
I know this because when I call the package from the command line it
runs ./bin/cli.js in the package as expected, but then throws:
Error: Cannot find module '../src/index.js'
Require stack:
- /usr/lib/node_modules/diffcraft/bin/cli.js
The error even references the line in ./bin/cli.js where the index
file is required, so that's definitely where the problem is.
I also know this because I checked the folder where the module is
installed globally and while the bin folder is there, the src
folder isn't. So the main code for my package just isn't there.
After discovering this, I even patched package.json to ensure that ./src/index.js was explicitly whitelisted in the files array. I hadn't done this before as NPM guidance states that whichever file is listed under main is also automatically whitelisted. But even including the file in files explicitly hasn't worked.
For reference, I don't have an .npmignore file.
I've got a horrible feeling I'm missing something simple and basic... Any ideas why my main file might be being skipped?
The package is diffcraft.
It works if you omit the ./ in front of the files (tested with npm 6.14.4 on Windows):
"files": [
"bin/cli.js",
"src/index.js"
],
This might be a bug in npm.
You can check this without publishing by running npm pack and checking the archive file.
Alternative is using an .npmignore file.
I'm working on a Javascript project, and as it so happens one of my dependencies pulls in puppeteer, which in turn downloads a whole copy of Chromium into my node_modules. My larger project is split into multiple Javascript packages, so I end up with multiple identical copies of Chromium among other stuff.
Is there a way to deduplicate these packages system wide? Note, npm dedupe seems to do something completely different to what I want.
I imagine there would be a module repository in my home directory which contains every package I need (in every version needed), and then in the local node_modules directories would contain only symlinks to the repository. This seems like an incredibly obvious optimisation, but I can't find any way to do it in npm. If not in npm, is it maybe possible in yarn?
As an added complication, this should also work on Windows (where symbolic link support has historically been not so good).
It seems the following command does what I want:
npm config set link -g
Then delete node_modules, and do npm install again. It should be much smaller now.
The documentation says:
If true, then local installs will link if there is a suitable globally installed package.
Note that this means that local installs can cause things to be installed into the global space at the same time. The link is only done if one of the two conditions are met:
The package is not already installed globally, or
the globally installed version is identical to the version that is being installed locally.
I am not sure if this has any negative side-effects - for example clobbering the global namespace with commands I don't want. For now, it seems to work fine.
Always feel stupid asking here because people are always confused with my questions, or I have a dumb problem, but, I'm working on a program in node.js and the text editor I'm using (NP++) doesn't seem to like to save files in the system32 directoy, (The directory where my modules are), and that is where my script is as well. (So I have .../.../node_modules/(modules) and .../.../node_modules/script.js) this becomes a pain when I want to edit the script, I have to clone the script to my desktop, then edit it, then overwrite the one in the node_modules directory. I tried saving the script to my desktop and running it, but it just gives me an error of module not found. (In my script I have the modules as var example = require('example.js')) Is there any way I can get it to get the modules from the node_modules directory, while keeping the script file somewhere easily accessible and editable? (i.e desktop?) (Sorry if this is confusing, not the best at these kind of things)
I'm not 100% sure that this is what's happening because I haven't used npm on Windows, but it sounds to me like you're installing your dependencies globally using npm -g. The more proper way to use Node is to install your dependencies locally, using npm without the -g flag. That way your dependencies get installed in your current working directory.
For example, let's say you've saved your project in a directory on your Desktop, and your script uses require("lodash"). If you cd to your directory and run npm install lodash, then the lodash module will be available to your script.
I work on two repositories at once. One depends on the other (listed in package.json dependencies).
So I am using npm link ..\theOne in other to work on both modules at once. As a result I can test the modification on one module on the other. Problem is when doing npm shrinkwrap on this other module: it will generate errors like:
npm ERR! extraneous C:\other\node_modules\theOne\node_modules\{xxxx}
{xxxx} is a dev dependencies that appears as extraneous for npm.
Anyone has succeded to shrinkwrap a module with symlink to another modules?
NB:
npm 3.10.3
node 6.3.0
I post a solution here. It doesn't explain how to shrinkwrap symlinks but I found a better workaround to develop multiple modules at once with dependencies between those modules.
The solution is to use an alternative to npm link to handle the modules relations during development: Instead of having a folder A linked to another folder B (aka symlink), the solution is to have the modified files from B copied in folder A. This solution is very powerful because it avoid getting node module shrinkwrapping error due to unwanted modules from B. How to do it:
On Mac
You can use wml: Wml listens to changes in some folder (using Watchman) and copies changed files into another folder. I never use it but my teammate using Mac use it every day.
On Window
I use DSynchronize (after clicking this link, scroll down to see the executable). DSynchronize is a stand-alone utility that let you periodically synchronize two or more folders. You can exclude from copying some folders (like node_modules) or include others (like lib). The configuration file DSynchronize.ini can be edited with a text editor. For example:
Source0000=-C:\DEV\workspace\js-common
Destination0000=-C:\DEV\workspace\connexme\node_modules\js-common
Filter0000=
VolumeSerialOri0000=407325536
VolumeSerialDest0000=407325536
ExcludeFilter0000=0
NoSubDirectory0000=0
NoFilterDirectory0000=1
DateBeforeToExcludeFiles0000=00:00:00
FilterFolder0000=\.git|\.vscode|\node_modules
This configuration will copy file from C:\DEV\workspace\js-common to C:\DEV\workspace\connexme\node_modules\js-common. This way, when I npm shrinkwrap my project connexme, I'll doesn't get extraneous bad folder from js-common folder.
Just a three last things about editing DSynchronize.ini for DSynchronize configuration:
Using it or closing it will save the configuration in DSynchronize.ini so be careful when editing DSynchronize.iniand the closing it. It will override DSynchronize.ini.
Make sure each variables is unique. Example: Source0000, Source0001...
Make sure to have all the variables present for each Source/Destinations (see example above).
I want to use gulp on my windows machine and it actually works pretty fine, unless I try to use the created files (like pushing to github or deleting). Then it breaks, because the filepaths are too long and it seems to be a fairly common problem. https://github.com/joyent/node/issues/6960#issuecomment-45569604
I understand that the problem arises through npm's nested directories, which extend the maximal char count for Windows directories, but in my understanding there is not any solution yet.
As I see it right now I have three options:
Try to reduce the chars of npm's directories, by changing the default from 'node_modules' to 'n_m' and hope that problem ist postponed. Like suggested here:
https://github.com/joyent/node/issues/6960#issuecomment-45569604
Then it is my question, how exactly do I change the default 'node_modules' directory name?
Change my development environment to Ubuntu, which is frankly a solution I dislike, because I've never used Ubuntu.
Stop using gulp overall.
So, how do I change the default 'node_modules' directory created through npm or what solution do you actually suggest?
There is one more tricky option.
Main problem is that gulp has a lot of nested dependencies and it creates very long nested file pathes.
But if you install some of npm modules that gulp requires in your main node_modules directory gulp will not download them as nested.
Currently you have something similar to (this may be not real path you have but idea is the same):
\node_modules\gulp\node_modules\lodash.bind\node_modules\lodash._createwrapper...
If you will add "lodash.bind" module to your project's package.json as dependency it will be installed in one level with gulp and not as gulp's dependency
\node_modules\gulp
\node_modules\lodash.bind\node_modules\lodash._createwrapper
And this will shorter all urls. You will need to fix only one or two with the longest pathes and it will work.
In my project it was enough to add this dependencies: “lodash.createcallback” and “lodash.bind” to package.json to fix everything.
Take in mind that befor doing this you probably would need to clear current node_modules folder. If you are not able to do that because off too long url you can create symbolic link to temporary short file path and delete it.