DEV Community

Discussion on: Bringing Modern JavaScript to Libraries

Collapse
 
jamescoyle profile image
James Coyle

I think the esnext option makes the most sense. There is no way for a library to know what its users are targeting so it can only make best guesses and support a couple of different options. It makes more sense to leave the transpilation to the consumer who can have more control over the level of support they need.

This makes things easier for the library developers as they can just focus on targeting the current browsers and, with the right tooling, the consumers of the library can easily transpile that code to support whatever configuration they need. No more messing around getting commonjs modules and esmodules to work together and much less useless code that adds unneeded browser support when you are creating a bundle for modern browsers. We can all just write code once for modern browsers with the latest widely supported features and then let the build tools handle legacy support.

I feel like the issue of outdated transpilation could be alleviated by having the build tools check for updates automatically and trigger warnings. Alternatively, assuming all transpilation will be done through babel, the library could add babel as a peer dependency with a minimum working version that would then trigger missing dependency warnings if the consumer uses an older version which doesn't support the newer features.