Library is broken in non-ES6 browsers

[th0r]

All the versions >= 5.0 are broken in browsers that don't support ES6 because of this line:

filesize.js/tsconfig.json

Line 9 in 3a088db

"target": "esnext",

It may potentially break even evergreen browsers because target: "esnext" doesn't transpile ESNext code at all which means output may contain unstable ES features (stage-4) which are not yet supported by the browsers natively.

[binarykitchen]

Yeah, same here. "browser": "lib/filesize.js" should point to a ES5 compatible script.

[th0r]

@binarykitchen no, it contains function arguments with default values - it's ES6.

[binarykitchen]

Yep and that's breaking on IE11. Can't we transpile it to ES5?

[avoidwork]

Yeah, just don't use 5.0; anything it might use won't exist in browsers you shouldn't be supporting today.

[binarykitchen]

Why not package an ES5 version within and refer to it in package.json? Have it transpiled before publishing? Many good npm libraries do that.

[avoidwork]

that's the way i had it for years, and then someone opened a PR to update the toolchain and output, and it seems reasonable because you shouldn't be supporting es5 in 2019 https://www.zdnet.com/article/microsoft-security-chief-ie-is-not-a-browser-so-stop-using-it-as-your-default/

[avoidwork]

I believe the rationale of the other PR was that you'd webpack today if you needed an es5 output, because there's now an esm file.

[binarykitchen]

Well, webpack's or browserify's default config is NOT to transpile any node modules. Hence they should already come with ES5 entry points.

And IE11 still hasn't reached end of life yet, still about 3% use it.

[avoidwork]

The company that produces it has had their chief security officer publically state that you shouldn't use it.

I don't use webpack, so this isn't an issue from my pov.

[th0r]

@avoidwork it's a common practice in libraries world to transpire to es5 by default to support IE or transpire to ES6 and mention in the readme that if you still have to support IE then use v4.

Another thing is your TS target is ESNext and your build may potentially break even in the latest Chrome as I mentioned in the main post.

[avoidwork]

@th0r common is whatever you think is popular. I didn't make the change, so open an issue and flag the original author if you'd like to converse with the right person.

[th0r]

common is whatever you think is popular

All the libraries/frameworks I know provide es5-transpiled code in the main field of the package.json.

[avoidwork]

cool story. this one did as well until someone in the community removed it. ergo, your statement is just relative to yourself (not a bad thing, just stating a fact). you don't have to run 5.x

[th0r]

I didn't make the change, so open an issue and flag the original author

Hmm, here is the PR with the change: #104
And all the commits there are yours.

And here is another opened issue with the same problem: #109

[avoidwork]

oh right, it came in that way. same deal applies, it's just modernized the same way. if you want to change it, so you can get the form you want just open the PR.

[avoidwork]

for context, i don't care about supporting browsers stuck on es5 syntax, and i don't support/use any tooling that requires it. ergo, i don't care, but i won't block anyone returning it for whatever reason; i'd assume that'd be another major bump?

[avoidwork]

@th0r why aren't you able to follow this example? avoidwork/tiny-lru#27 (comment) there's a reference of es2020 I'm not grasping how 1 project rolls forward fine* and this one doesn't.

[avoidwork]

I've reverted & rolled forward with 6.0 'cause this isn't required from my pov and it's totally screwing you over, so lose/lose.