Closed 1jerry closed 10 years ago
This isn't a problem in roots and it's not exactly npm's fault either - they use UNC paths for everything, which is how they are able to make that structure in the first place (see: https://github.com/npm/npm/issues/3697). It's really a problem with Windows APIs (including Windows Explorer) not being able to utilize the real maximum NTFS filepath length of 32,000 characters. But npm is working to make a better way to deal with this limitation (see: https://github.com/joyent/node/issues/6960#issuecomment-46704998)
As a workaround, if you want to remove a folder, you can do npm install -g rimraf
and then use the rimraf bin to do rimraf path\to\folder
.
Yeah, unfortunately it does not look like we can do anything about this. I used the smaller lodash modules because charge can be used by itself without full lodash, so didn't want to add unnecessary dependencies. But apparently even the regular lodash package causes this issue, along with a number of other libraries that use deeply nested dependencies. This is unfortunate, but there isn't really much we can do about it until either windows or npm fixes it up.
I really would like roots to work with windows, but this seems like a very difficult issue to work around, since it really is very far outside of roots itself. If the compromise we have to take in order to get it working on windows is to include unnecessary dependencies, I wonder if that's actually worth it...
This shouldn't cause roots to totally "break", you're just not able to use Windows Explorer or other software that relies on poorly written Windows APIs to manipulate the directory structure that roots is installed in. You should still be able to run and use roots.
That is correct. I didn't mean to say it didn't work. I just had problems deleting and copying the file structure.
On Fri, Sep 19, 2014 at 5:07 PM, Sean Lang notifications-at-github.com |git-73ry| 1fn1zhbp1t@sneakemail.com wrote:
This shouldn't cause roots to totally "break", you're just not able to use Windows Explorer or other software that relies on poorly written Windows APIs to manipulate the directory structure that roots is installed in. You should still be able to run and use roots.
— Reply to this email directly or view it on GitHub https://github.com/jenius/roots/issues/557#issuecomment-56250305.
Ah ok. While this is unfortunate, because it's an issue with node and windows rather than with roots, I'm going to close this out so we can stay focused. If anyone have a potential solution that does not involve making the project less efficient, I would be happy to discuss and merge this in!
Just a heads up. lodash v3 has significantly reduced the dep graphs of its modularized packages:
lodash.assign@3.0.0
├─┬ lodash._baseassign@3.0.1
│ ├── lodash._basecopy@3.0.0
│ └─┬ lodash.keys@3.0.3
│ ├── lodash.isarguments@3.0.0
│ ├── lodash.isarray@3.0.0
│ └── lodash.isnative@3.0.0
└─┬ lodash._createassigner@3.0.0
├── lodash._bindcallback@3.0.0
└── lodash._isiterateecall@3.0.1
and
lodash.remove@3.0.0
└─┬ lodash._basecallback@3.2.0
├─┬ lodash._baseisequal@3.0.1
│ ├── lodash.isarray@3.0.0
│ └── lodash.istypedarray@3.0.0
├── lodash._bindcallback@3.0.0
└─┬ lodash.keys@3.0.3
├── lodash.isarguments@3.0.0
├── lodash.isarray@3.0.0
└── lodash.isnative@3.0.0
You can also cherry-pick modules from lodash
, for example require('lodash/array/chunk')
.
The dependency chain in module charge for using lodash is creating file paths that cannot be copied or deleted in Windows.
Problem: Package charge has "lodash.assign" and "lodash.remove" as dependencies. Each of those packages has mutilple "lodash..." package dependencies to nine levels!. This might not be a problem in posix, but Windows has a limit to the number of file path characters. Example directory that I cannot open in Windows:
Suggestion:: It seems that almost every aspect of lodash is being used but right now they're all over the place. It appears you already have the whole lodash package as a first level requirement anyway. Why not just have charge require that?