Remove unnecessary step with number separator from Color function#208
Conversation
AFAIK `object &= 0xFF_FF_FF;` was an unnecessary step, because `object & 0xFF` is equivalent to `object & 0xFF_FF_FF & 0xFF` and `(object >> 16) & 0xFF` is equivalent to `((object & 0xFF_FF_FF) >> 16) & 0xFF` This should prevent the error described in https://github.com/Qix-/color/issues/204
Then an issue needs to be filed with the Vue team as they do not support modern Javascript. I'll accept this PR as it is definitely a no-op but not because it solves a syntactic problem. I linked to that as it is directly the spirit of modernizing code. That's all. The library is standard javascript, it's just too new for your specific project. That stance I will not budge on, sorry. |
|
Published as |
|
@Qix- thank you for accepting the PR
Just to share a bit more context. With Vue cli default config, I can use numeric separators in my own code and it will transpile it using https://webpack.js.org/loaders/babel-loader/ under the hood, so I think that they do support modern Javascript. But everything inside |
|
Yes but if Vue's parser doesn't support it then it's missing an accepted and standardized feature of Javascript. They should be able to implement it quickly and push out a fix that doesn't require babel. My package isn't the place to fix that; I've done my due diligence with the major release cycle. The alternative is to ask the XO.js team to remove that rule but I don't see them doing that. |
2 participants
@Qix- I'm sorry that my comment https://github.com/Qix-/color/issues/204#issuecomment-889933878 came across as demanding and thankless. I'll try to be more constructive and look for a solution that is aligned with your aims of this project. What do you think about the change in this PR? Unlike transpiling, it should AFAIK not add any maintenance cost.
AFAIK
object &= 0xFF_FF_FF;was an unnecessary step, becauseobject & 0xFFis equivalent toobject & 0xFF_FF_FF & 0xFFand(object >> 16) & 0xFFis equivalent to((object & 0xFF_FF_FF) >> 16) & 0xFFThis should prevent the error described in https://github.com/Qix-/color/issues/204
There is just one more place that would throw a similar error:
color/index.js
Line 257 in 694d197
Note that I don't have anything against ESM. I have read through https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c that you recommended and I didn't find there anything about ECMAScript 2021 features (such as Numeric separators). I'm using ESM in my code that is built/compiled with https://cli.vuejs.org/. It also works well with ESM in NPM dependencies that use the
package.jsonmodulefield. The only thing that is causing issues is ES2021 numeric separators.