Should published npm packages target ES5 syntax?

Question

A bit of background:

I've been using Webpack with babel-loader for a while and overall the experience has been hugely positive.

Yesterday, I published an npm package of my own (to a private registry), and installed it into my "main" project that uses Webpack.

What I was surprised to find was that when I built the main project with Webpack, the code from my npm package was not transpiled into ES5 syntax, but retained all the ES6 syntax that was in it.

It appears this is because my webpack.config has this exclude setting, which is strongly recommended by the babel-loader documentation and included in its examples:

{
   test: /\.m?js$/,
   exclude: /(node_modules|bower_components)/,     // <--  here
   use: {
      loader: 'babel-loader',
      options: {
          presets: ['@babel/preset-env']
      }
   }
}

This much more or less makes sense. What confuses me is that I have never encountered this situation before, across the hundreds of packages and indirect dependencies I've consumed in my projects.

This makes me wonder if every one of those packages was transpiled to ES5 syntax before publishing to NPM. Up until now, I had assumed that people just published the code they had, and that Webpack+babel-loader took care of the necessary transpilation.

So my question is:

Is there some unwritten rule that NPM packages that have any possibility of being used in IE should be transpiled to ES5 syntax before npm publishing? Or is there something that I'm missing?

Clarification: My question assumes that we are talking about a package that is designed to be ES5-compatible once it is transpiled and the necessary polyfills are included. The question is whether it is typical for the code to be transpiled prior to publishing to npm, because up until yesterday, I thought that it was the norm for the package consumer's build process to take care of that step.

Answer 1

There is only one rule which is that you publish what makes sense to you.

What makes sense to you is typically a trade-off between what features you expect your users to have available and what (lack of) features you have the resources to support.

If 10% of your users cannot use ES6, but supporting ES5 costs you 50% of your time, you need to determine whether gaining 10% of users is worth paying 50% of your time.

In my case, I know that 100% of my users have at least ES2019 plus some stage-3 and assorted stage-2 proposals, so that's what I use, and I don't bother with anything below ES2019.

Others may have a user base that is stuck on Windows XP with IE 8, and for them, dropping support for IE 8 would mean losing 100% of the user base.