doceazedo / emotettv Goto Github PK

Setup lint-staged and Husky to run the ESLint and Prettier checks.

Setup cross-fetch to make the library compatible with browsers, Node and React Native. I think it would be better to use it as a polyfill, but not sure if there are any drawbacks.

Instead of the parseEmotes and parseBadges functions returning their parsing results based on predefined formats, multiple chain functions shall be added to return different formats.

The following methods will be responsible for returning the internal parsed formats - the ones that are currently returned by default:

• parseEmotes(...).toWords()
• parseBadges(...).toBasicArray()

The following methods shall be implemented to return different formats for user convenience:

Method:

parseEmotes(...).toHtml(size?: number) => Promise<string>

Description: Returns a string with the original message and emote codes converted to <img>

Input: Hi HeyGuys I'm an example message! popCat

Output:

Hi <img src="..." alt="HeyGuys" /> I'm an example message! <img src="..." alt="popCat" />

Method:

parseBadges(...).toHtml(size?: number) => Promise<string>

Description: Returns a string with the user badges converted to <img>

Output:

<img src="..." alt="broadcast" /> <img src="..." alt="subscriber" /> <img src="..." alt="premium" />

Method:

parseBadges(...).toMinimalArray() => Promise<BadgesMinimalArray>

Description: Returns a simplified version of the badges array, with only the image URLs in all sizes

Output:

type BadgesMinimalArray = {
  image_url_1x: string;
  image_url_2x: string;
  image_url_4x: string;
}[];

Badges parser are not working due to the legacy endpoint sunsetting: https://discuss.dev.twitch.tv/t/legacy-badges-endpoint-shutdown-details-and-timeline-june-2023/44621

• The ffz service should be merged with the bttv one, as they use the same API.
• The services folder shall be deleted and its files moved to their related modules, renamed as <module>.service.ts.
• Every module that uses custom types shall have a <module>.types.ts file exporting all of its types.

Implement 7TV emotes. Docs. Handle overlay/zero-width emotes. Handle personal emotes.

Later, also parse badges (#16).

Should we handle other stuff?

• Custom name colors
• Custom profile pictures

Add an options parameter for more flexibility and remove channelId in favor of it.

type ParseEmotesOptions = {
  channelId?: string;
  thirdPartyProviders?: {
    bttv?: boolean;
    ffz?: boolean;
  };
  customEmotes: EmotesFactory | EmotesFactory[]
}

Descriptions:

• channelId being optional will allow the use of only global or custom emotes
• thirdPartyProviders will allow to toggle third-party emotes and help adding others in the future
• customEmotes will allow the use of custom emote factories, provided by the user

All third-party providers will be defaulted to true.

Everything described on issue #10 should also be done for parseBadges, but that will require to add BTTV and FFZ badges to the parser.

Only FFZ channel emotes are being fetched, global emotes endpoint was never implemented.

If emotettv is used to parse messages from different channels, the store of every channel emotes will have their own copy of the global emotes yet they could be shared.

My proposal is to add a globaEmotesStore alongside channelEmotesStore.

This could also be achieved by adding a global key alongside the other channel IDs in the channelEmotesStore, but I think the first option is more elegant.

Add these methods to the lib:

• reloadEmotes(options)
• clearEmotes()
• reloadBadges(options)
• clearBadges()

The reload functions should expect those same options of type ParseEmotesOptions described on issue #10.

As this wouldn't break any existing code, it could probably be delayed to later v1 release.

Currently, only official Twitch badges are being parsed. We should also parse badges for:

• BTTV
• FFZ
• 7TV

It would be nice to have an action to run these steps on every pull request open:

• Run linting and formatting checks
• Run Jest tests (yet to be created on: #6)
• Run build

And an action to run these on creating a new release:

• Run build
• Bump version (according to the release)
• Publish package to NPM

I'm totally open to suggestions on the best way to document this project :) These are some of the alternatives I was thinking of:

• Just create some Markdown files on a "docs" folder
• Use Docz or some other alternative
• Create a static website with Astro

If we create a static website for the docs, It would be cool to get all the info the we can automatically.

It would be cool to setup Jest with a few simple tests and add more complex ones later (using TMI.js, for example).