Bower 1.8.x: Main field precedence compatibility boundary remains undefined

Unresolved main field precedence in Bower 1.8.x

When a package declares both main in bower.json and main in package.json, Bower 1.8.x exhibits ambiguous behavior in determining which file is authoritative for the dependency's entry point mapping. The Bower documentation states that main serves as a hint for file mapping, but does not specify a resolution order or precedence rule when both manifest formats are present in the same package.

This creates uncertainty for consumers who rely on Bower to resolve correct file paths during bower install, particularly when integrating packages that have been partially migrated from npm to Bower or maintain dual package management. The lack of explicit precedence in the documented behavior means that the outcome may depend on internal implementation details that are not guaranteed to remain consistent across versions or may vary depending on package structure.

While Bower is officially deprecated and unmaintained, the documented configuration boundary around .bowerrc resolution is well-defined, but this specific interaction between bower.json and package.json main fields remains underspecified in the official documentation.

Which main field takes precedence when both bower.json and package.json are present in a package, and is this behavior consistent and documented across Bower 1.8.x versions?