Comment by jcranmer
7 years ago
It is actually surprisingly common to hit the max path length with build systems. Why?
You're building a project. Your source code is under C:\Users\twenty-ish character username\Documents\Projects\. The project name is a released build which got extracted to something network-configurator-1.4.5, which builds into a build directory underneath that. That's up to 80 characters right there, only 180 remaining.
If you have any process that starts doing something like "place the artifacts needed to build <result>.foo in result/" (say, cmake), and throw in some hierarchy nesting, you can chew up 180 characters remarkably quickly. Something like node.js produces this monstrosity of a path name:
./node_modules/istanbul-harmony/node_modules/handlebars/node_modules/uglify-js/node_modules/source-map/test/source-map/test-source-map-consumer.js
Names that seem reasonable within the context of their folder may turn out to be highly redundant in the context of the entire pathname--but many people would rather prefer to have readable names at each level of the folder hierarchy, which makes it hard to make full pathnames reasonable. Sometimes, these names are required by means of a language implementation or other build system that is uncontrollable by you.
The unreasonable thing here is not any of the components' names, and the problem fundamentally can not be fixed by shortening them. The problem is the insane uncontrolled nesting.
It just seems node.js is broken.
Hardly. "insane uncontrolled nesting" seems quite a natural way to manage complexity an a automated way. I can see no other principle but the Miller's law (the 7±2 "magic number") to label some level of nesting as "insane" and it doesn't apply for automated processing. What are, if any, good reasons to limit a path length so severely other than human readability? If long paths puts non-negligible penalty on performance I'd say the file system is defective by design.
Good reasons not to have many modules: Compile time, Website loads times and sizes, Project maintainability.
Nested dependencies have negative effects on all of those. They encourage uncontrolled addition of modules, and even addition of modules in multiple versions. They lead to wrong "isolationist" thinking.
In other words, they do not manage complexity but produce unneeded complexity.
1 reply →