-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to ESM #102
Move to ESM #102
Conversation
@Qix- any chance of a review? This would also support: https://github.com/Qix-/color/issues/256 |
I will add TypeScript declarations as well. |
This needs more changes to support tree shaking. I will handle this later. |
@Qix- Do you have some ideas for the tree shaking? I have two ideas, the first one is: import {rgb, keyword} from 'color-convert';
rgb.hsl(0, 0, 0);
rgb.hex(0, 0, 0);
keyword.rgb(0, 0, 0); Another idea is to make all convert functions to single one: import {rgbToHsl, rgbToHex, keywordToRgb} from 'color-convert';
rgbToHsl(0, 0, 0);
rgbToHex(0, 0, 0);
keywordToRgb(0, 0, 0); What do you think? |
I feel like a refactor for tree-shakability might be appropriate to have as a separate PR? Converting to ESM with the API "as-is" (this pr), and then updating for tree-shaking, potentially modifying the api in a breaking way, as a separate change. Thoughts? (that's, of course, assuming that the next major release waits for both PRs to land) |
Both are OK for me. That depends on @Qix-. |
Either way, appreciate all the work you've put in. Hopefully @Qix- gives it a look soon. |
@Qix- any chance on feedback here? This has been pending for almost a year |
could you release a separate package for the ESM version? |
Hi @Qix-, do you want to have a look? |
Looks good on a cursory once-over. Let's see what CI says, and get this merged finally. |
@Qix- Removed the unused script. |
Looks like CI is failing still, surrounding the types. I can try to look at this sometime later today or tomorrow if you don't have time, but as soon as this is green I'll check it out and do a release. |
Ah, my bad. I should run the test before committing new changes. I can handle this failing test. Which solution do you prefer? +/* eslint-disable import/no-duplicates */
import convert from './index.js';
import type {Channels, RGB, HSL, HSV, CMYK, LAB, LCH, HCG, HWB, XYZ, Apple, Gray, ANSI16, ANSI256, Keyword, HEX} from './index.js';
+/* eslint-enable */
-imoprt convert from './index.js';
-import type {Channels, RGB, HSL, HSV, CMYK, LAB, LCH, HCG, HWB, XYZ, Apple, Gray, ANSI16, ANSI256, Keyword, HEX} from './index.js';
+import convert, {type Channels, type RGB, type HSL, type HSV, type CMYK, type LAB, type LCH, type HCG, type HWB, type XYZ, type Apple, type Gray, type ANSI16, type ANSI256, type Keyword, type HEX} from './index.js'; -imoprt convert from './index.js';
-import type {Channels, RGB, HSL, HSV, CMYK, LAB, LCH, HCG, HWB, XYZ, Apple, Gray, ANSI16, ANSI256, Keyword, HEX} from './index.js';
+// eslint-disable-next-line @typescript-eslint/consistent-type-imports
+import convert, {Channels, RGB, HSL, HSV, CMYK, LAB, LCH, HCG, HWB, XYZ, Apple, Gray, ANSI16, ANSI256, Keyword, HEX} from './index.js'; |
Probably the second. I can see a case in the future where the conversions are built beforehand and thus the types are generated. Whatever makes the linter happy now is fine in the meantime. :) |
@Qix- Updated with the second option. |
Thanks, released as |
I've drafted a PR for tree-shaking support: |
Sorry for dragging my heels for so long on this. Been a strange string of years. Appreciate the patience :) |
Closes #57
Closes #103
Closes #104