Conflict when using color@4.0.0 with react-native #204

Hi. Whatever parser you're using doesn't support underscores in numeric literals. You need to open an issue with them.

@Qix- you are totally right, I can see opened issue here https://github.com/facebook/metro/issues/645.

Thanks.

@Qix- thanks for your reply https://github.com/Qix-/color/issues/206#issuecomment-887818922

Sorry about posting to that issue. My reasoning for posting to that issue was that its title ("4.0.0 fails to be parsed by webpack without transpiling") is describing the problem that I'm trying to address much better than the title of this issue ("Conflict when using color@4.0.0 with react-native").

@Qix- thanks for your reply https://github.com/Qix-/color/issues/206#issuecomment-887818922

Sorry about posting to that issue. My reasoning for posting to that issue was that its title ("4.0.0 fails to be parsed by webpack without transpiling") is describing the problem that I'm trying to address much better than the title of this issue ("Conflict when using color@4.0.0 with react-native").

➕ Same here

There is nothing to be done here, I'm not sure why you're saying "same here". Go ask them to implement modern Javascript syntax, or simply opt not to upgrade to the latest version of color. This is precisely why it was a major release. Please see https://semver.org if you're not familiar with how semantic versioning works.

There is nothing actionable here. You're facing bugs in other programs.

Go ask them to implement modern Javascript syntax,

@Qix- I don't think the problem is that some tools don't support modern Javascript syntax, but rather that not all browsers support it. People work on projects, that target also browsers like MSIE11. I just cannot target ES2021, because the global browser support of these features is about 90% https://caniuse.com/?feats=mdn-javascript_builtins_string_replaceall,mdn-javascript_builtins_promise_any,mdn-javascript_builtins_weakref,mdn-javascript_operators_logical_or_assignment,mdn-javascript_operators_logical_and_assignment,mdn-javascript_operators_logical_nullish_assignment,mdn-javascript_grammar_numeric_separators. So we need to add some config to transpile your code.

IMO You're creating unnecessary hurdles for developers using your package. I'm not sure how many developers, but I think it'll be most of those building web apps. Based on the NPM download stats of color being in the order of millions, I think we're talking at least about tens of thousands of developers. Even if someone decides not to upgrade, they still had to invest some time to understand the situation. Even if it were just 10 minutes per developer, given how widely color package is used, in sum we're talking about hours and days of work spent (wasted) on this.

I see the value of numeric separators in your source code, but I don't see why they cannot be transpiled in the distributed npm package.

or simply opt not to upgrade to the latest version of color.

Will you backport bug fixes and new features to 3.X?

This is precisely why it was a major release.

I see you're following SemVer properly, but I still don't see the value of the breaking change you decided to make. IMO It's just giving people more trouble than benefit.

Please read this: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

that target also browsers like MSIE11

IE is dead, I do not care to support it. Sorry.

IMO You're creating unnecessary hurdles for developers using your package.

Not really, this is why it was released as a major version. Those who wish to support deprecated and otherwise obsolete environments will need to transpile for those environments. It's been this way for almost 10 years.

Even if it were just 10 minutes per developer, given how widely color package is used, in sum we're talking about hours and days of work spent (wasted) on this.

That's not accurate nor is it fair, sorry.

I see the value of numeric separators in your source code, but I don't see why they cannot be transpiled in the distributed npm package.

Because transpiling for npm as a library has never worked well, it creates a ton of headache, it causes issues with debugging, it's poorly implemented, causes people who do bundle to have increased bundle sizes (perhaps not in color's case, but still).

Plus it's not something I want to support.

Will you backport bug fixes and new features to 3.X?

No.

I see you're following SemVer properly, but I still don't see the value of the breaking change you decided to make. IMO It's just giving people more trouble than benefit.

The entire codebase was updated automatically using XO's configuration, which is the linter/formatter that I use for this package. If you have an issue with the config there, please open an issue at https://github.com/sindresorhus/xo.

I'm going to lock this now. I've fought this same exact battle hundreds of times over the last decade. I'm tired of it, frankly. If I write the lowest common denominator of code, I would ultimately have to write ES5. Even then someone would complain.

I'm tired of keeping my code updated only for someone to tell me I'm wasting their time by not putting in enough of my free, unpaid time as I struggle IRL to make ends meet to begin with.

You're welcome to fork and maintain this code yourself. That's the beauty of open source. I'm getting sick of the demanding and thankless attitudes here though.