ck86
commented
10 years ago 1: I don't think the plugin should guess where are the main files of an package could be, but I could add an option something like defaultMain where you can define a fallback for all packages which have no main property defined. What do you think?
2: I will fix it. I also thought about another option debug for debugging purposes.
crfroehlich
See also #5 and #3.
Problem 1: Many of the packages available via bower do not have properly configured "main" properties. My bower overrides object is quite large.
The problem that the "main" property solves is clear: there is no consistency to the way that people assemble their npm packages. Some put everything for consumers in a /dist folder, sometimes content is organized into /js, /css folders. Sometimes the .min files are included; sometimes not.
Still, in the absence of main, there's a good 90% chance that you can match on package-name => package-name.js, package-name.css; and there's a very good chance that those files are going to be at /, /js /css, /dist, /dist/js, /dist/css. So it's a total hack, but might it not be possible to try to more aggressively fish those out?
It is a bit of a hack, but I'm not motivated enough to either submit bugs or pull requests on every project that is "broken" in this way.
The kitchen sink fix might be to do something like what bower does when it encounters a conflicting dependency. Say you're installing a jQuery plugin and bower doesn't know which version to use, you get a prompt with a numbered list of versions. Pick 1 and you're done. Likewise, you could display all the .js/.css files in the package and let the user pick which to add to an override. Definitely the kitchen sink.
Problem 2: Personally, if the task cannot find a "main" property directly or by fishing it out, I would much prefer that the task not fail. I'd rather it log the error to the console and continue processing.
It might also be nice to block and show the option to add an ignore override in the console.