jescalan / roots

a toolkit for rapid advanced front-end development
http://roots.netlify.com/
Other
1.45k stars 133 forks source link

V3 creating overly long file paths for Windows #557

Closed 1jerry closed 10 years ago

1jerry commented 10 years ago

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:

B:\VCS\temproots\node_modulesx\charge\node_modules\lodash.remove\node_modules\lodash.createcallback\node_modules\lodash._basecreatecallback\node_modules\lodash.bind\node_modules\lodash._createwrapper\node_modules\lodash._basecreatewrapper\node_modules\lodash._basecreate\node_modules\lodash._isnative

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?

notslang commented 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.

jescalan commented 10 years ago

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...

notslang commented 10 years ago

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.

1jerry commented 10 years ago

That is correct. I didn't mean to say it didn't work. I just had problems deleting and copying the file structure.

Jerry

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.

jescalan commented 10 years ago

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!

jdalton commented 9 years ago

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').