Around those, there are several packages that are already compiled for a given system. Some library authors decide – usually in a goodwill – what browser/node versions the package supports. This way browser/node compatibility is set ahead of time. But it doesn’t feel right.
What library developers should bear in mind is that the end product developer expects all their modules to compile only for the target they want. We can’t know what target that is ahead of time.
The end product usually has more than one library as a dependency. A library setting its own support table makes the end-product developer lose control of their app and what browsers need support. By taking control from builders to decide this, the end result can have lots of polyfills and unnecessary code, leading to poor performance.
Library developers should be agnostic when it comes to browser/node support and use the latest in ECMA standards. It is not their responsibility but the developer building the end product to know what engines and browsers the library needs to support. Only builders should have the final word if that given software should be supported and transpile it accordingly.
Library developers should focus on making developers feel productive and in control. The end-product developer should use tools available to speed-up their process. Library developers should worry about the developer experience. Product developers about the user experience. The web has a lot of things to think about and library developers should not add more to the stack of things the end-product developer should be worried.