refactor!: better cross runtime support

[Wykerd]

Description

This builds on efforts of #91 and intends to make the library work on browsers and Deno (possibly CFWorkers) by replacing as much dependencies as possible with equivalent Web APIs available on all platforms.

This is a major change which will break event and stream APIs as these are to be replaced by their Web API equivalents.

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Changes:

• Remove node APIs
  • crypto -> SubtleCrypto
  • stream -> Web Stream API
  • events -> EventTarget
  • make sure buffer is polyfilled on all platforms
• Replace Axios with Fetch API - Fetch is available on more platforms than XMLHTTPRequest
• Documentation for Deno usage
• Update tests for browsers
• Documentation for browser usage
• Tests for Deno?

EDIT: will not support Bun.js at this time, too experimental at this moment.

[Wykerd]

I now realize that this is going to cause massive merge conflicts with #93, but how bad could it be 😅

[LuanRT]

events -> EventTarget

Maybe we could work on a custom implementation of EventEmitter? It seems quite simple and would probably be better compared to the verbosity & weirdness of the EventTarget API.

[LuanRT]

I now realize that this is going to cause massive merge conflicts with #93, but how bad could it be 😅

Haha there's already a quite big conflict due to 68cb841 (which was an inevitable change as we had lots of dead code laying around). I guess we could help but unfortunately he's working on a branch outside of the project.

[Wykerd]

How about this for EventEmitter? Best of both worlds haha

[LuanRT]

Awesome!

[Wykerd]

I'm going quite out of the scope of this PR by doing so much TS conversion too, but I cannot write my new changes in TS without then also converting some of the other parts of the project to TS too.

[LuanRT]

I'm going quite out of the scope of this PR by doing so much TS conversion too, but I cannot write my new changes in TS without then also converting some of the other parts of the project to TS too.

At this point this probably supersedes @MasterOfBob777's PR.

[Wykerd]

I'm going quite out of the scope of this PR by doing so much TS conversion too, but I cannot write my new changes in TS without then also converting some of the other parts of the project to TS too.

At this point this probably supersedes @MasterOfBob777's PR.

There's no way I'm rewriting all the parsers to TS in this PR though, so there's still a lot of work to be done if we want the entire codebase to be TS, for now I've enabled allowJS in the tsconfig

[BobVarioa]

Wow! This is very cool! As @Wykerd mentioned I do think my PR has its place, but I think it is probably best to wait until this PR is completed to avoid merge conflict hell.
I also just want to mention it might be better to compile for each platform separately with esbuild constants, instead of programmatically figuring out the runtime, as it increases bundle size by quite a bit if you include unnecessary code in their respective platforms (Also the exports field in package.json can also achieve a similar effect by swapping out modules by path.) Regardless this isn't a huge issue at the end of the day, because it would barely effect performance, as V8 and other engines should just realize those branches are impossible to reach and "remove" the check, and basically achieve the same thing.
Those are just my two cents though it might not be the right decision in this case.

[LuanRT]

I think Innertube#session.signIn() doesn't wait for the authentication to finish.

Ex:

//...

// Triggers the auth event and asks the user to authorize the authentication.
await yt.session.signIn(undefined); 

// This will return true even though authorization hasn't been granted yet.
// In fact, this should not be printed at all since the auth flow hasn't finished and any InnerTube call will inevitably fail.
console.log(yt.session.logged_in);

[Wykerd]

I think Innertube#session.signIn() doesn't doesn't wait for authentication to finish.

Ex:

//...

// Triggers the auth event and asks the user to authorize the authentication.
await yt.session.signIn(undefined); 

// This will return true even though authorization hasn't been granted yet.
// In fact, this should not be printed at all since the auth flow hasn't finished and any InnerTube call will inevitably fail.
console.log(yt.session.logged_in);

It does not, it only waits until the first auth event is fired with the login code

[Wykerd]

Should I make it wait instead? Probably makes more sense if it does.

[LuanRT]

Should I make it wait instead? Probably makes more sense if it does.

Yup, not doing so would probably cause some confusion.

[BobVarioa]

Just a few small comments I had. Nothing that seem like a huge issue, or a glaring bug, but since this a large PR I most definitely missed something, and frankly I don't have a large amount of experience with the library.

[Wykerd]

Just a few small comments I had. Nothing that seem like a huge issue, or a glaring bug, but since this a large PR I most definitely missed something, and frankly I don't have a large amount of experience with the library.

I do think there will be some small bugs that slipped through the cracks here and there, especially in the JS code. They should be easy to find once the project is completely migrated to TS.

[Wykerd]

Whoops assigned this to myself accidentally 🤣

[Wykerd]

I think this PR is ready to be merged now. Mind giving it a look @LuanRT ?

[LuanRT]

This should be item_type, MusicResponsiveListItem represents one single item inside a list, and not a list. It may also be mixed with other items (ex; in YTMusic's home feed).

YouTube.js/lib/parser/classes/MusicResponsiveListItem.ts

Line 95 in e772b86

this.list_type = ('video');

[LuanRT]

I don't see any other major bug, so merging now. Thanks @Wykerd!