Closed 00dani closed 11 years ago
It's looking good but people don't always use the "components" directory. We'll need to look up the "directory" entry in bower.json (probably in their API somewhere), so we check the right dir. I personally put stuff in public/scripts/vendor
a lot of the time, for example.
Excellent point. It looks like bower ls --paths
gives you the path to the component's directory if there isn't a main
entry, so I've queried the paths in the above commit, and that seems to work. Thoughts?
(It might be slightly nicer to run both the map
and paths
calls in parallel instead, but it only runs once anyway so it mightn't matter much.)
That seems like a pretty good solution. Yeah.. annoying how many things don't have a main or even a bower.json. I'll merge and publish this now. Thanks for the PR.
It turns out there are lots of Bower components that don't specify their
main
file! In addition, there are plenty of Bower components that don't actually have abower.json
orcomponent.json
at all, and the one Bower automatically generates also lacks amain
field.Previously debowerify couldn't cope with those particular components at all. I noted, however, that many components simply have a main file named after the module itself; having debowerify "guess" that the module's entry point is at
moduleName.js
, when not told otherwise by amain
field, will allow for many more components to be debowerified without manualbower.json
modification.If a module's entry point isn't at
moduleName.js
, an error is now produced along the lines of "module not found: ../components/moduleName/moduleName.js", which I think is as clear as the error that used to be produced for this case (a simple "module not found: moduleName"), with the added advantage of hinting (somewhat) toward the fact that the missingmain
field is the source of the error.