Improve JSDocs to be more descriptive and better overall

[Reishimanfr]

I've improved all relevant JSDocs across files Player.ts, Poru.ts, Queue.ts, and Response.ts so they have a more descriptive JSDoc comment. I also fixed some spelling issues/sentences that made no sense.

Breaking changes:

• I've changed the player.stop method to player.skip instead as stop implies a complete stop of the player's playback where skip implies skipping the currently playing song
• I've removed the unnecessary parameter from poru.init (that being the client parameter) as it's already provided in poru's constructor

[UnschooledGamer]

Why was the jsdoc removed of loop type?

[UnschooledGamer]

This is probably an invalid param as there no param called as options defined in the resolve function

[UnschooledGamer]

I've improved all relevant JSDocs across files Player.ts, Poru.ts, Queue.ts, and Response.ts so they have a more descriptive JSDoc comment. I also fixed some spelling issues/sentences that made no sense.

Breaking changes:

• I've changed the player.stop method to player.skip instead as stop implies a complete stop of the player's playback where skip implies skipping the currently playing song
• I've removed the unnecessary parameter from poru.init (that being the client parameter) as it's already provided in poru's constructor

Overall looks Good, Discussing about the breaking changes firstly the player.stop

"implies a complete stop of the player's playback"

true, that's actually what it does completely stops the current playing track.
secondly client parameter is present probably to provide the updated client data as <Poru>.init would be run once the discord client is ready(fully connected to discord) and before that client won't have access to it's user id.

I might be wrong don't mind it and correct me.

Apart from this I'll wait 24h for @parasop to review if he doesn't in 24h I'll merge this. (If I don't or forgot to do so Kindly Reminder me 😅)

-- Thanks UnschooledGamer

[Reishimanfr]

secondly client parameter is present probably to provide the updated client data as .init would be run once the discord client is ready(fully connected to discord) and before that client won't have access to it's user id

The thing about the client (at least for discord.js, not sure about other libraries) is that you can't access the user property if it's not initialized. I didn't see any other references to the client parameter inside of the init method which made me think it's superfluous.

[Reishimanfr]

true, that's actually what it does completely stops the current playing track.

As a user of the library I avoided the stop method as I figured it would completely stop the player and disconnect it from the voice channel similar to what destroy does hence why I renamed it to a more straight-forward skip instead. It may just be me but I feel like skip would work better here.

[UnschooledGamer]

secondly client parameter is present probably to provide the updated client data as .init would be run once the discord client is ready(fully connected to discord) and before that client won't have access to it's user id

The thing about the client (at least for discord.js, not sure about other libraries) is that you can't access the user property if it's not initialized. I didn't see any other references to the client parameter inside of the init method which made me think it's superfluous.

It's most likely the same as after the bot successfully connects discord Gateway it returns the information about the user id etc.

[Reishimanfr]

Probably yeah. So the client parameter seems to be redundant here then.

[UnschooledGamer]

true, that's actually what it does completely stops the current playing track.

As a user of the library I avoided the stop method as I figured it would completely stop the player and disconnect it from the voice channel similar to what destroy does hence why I renamed it to a more straight-forward skip instead. It may just be me but I feel like skip would work better here.

stop just tells Lavalink to stop the current playing song that's all. The disconnection afterwards is probably by code written somewhere.

[Reishimanfr]

true, that's actually what it does completely stops the current playing track.

As a user of the library I avoided the stop method as I figured it would completely stop the player and disconnect it from the voice channel similar to what destroy does hence why I renamed it to a more straight-forward skip instead. It may just be me but I feel like skip would work better here.

stop just tells Lavalink to stop the current playing song that's all. The disconnection afterwards is probably by code written somewhere.

I'm not saying stop disconnects the bot from the voice channel, just saying that's what it feels like it would do

[UnschooledGamer]

true, that's actually what it does completely stops the current playing track.

As a user of the library I avoided the stop method as I figured it would completely stop the player and disconnect it from the voice channel similar to what destroy does hence why I renamed it to a more straight-forward skip instead. It may just be me but I feel like skip would work better here.

stop just tells Lavalink to stop the current playing song that's all. The disconnection afterwards is probably by code written somewhere.

I'm not saying stop disconnects the bot from the voice channel, just saying that's what it feels like it would do

Ah, doesn't feel for me. stop means it stops the player and destroy means it destroys the player.

[Reishimanfr]

Still, I feel like skip is just a better name for a method if it's supposed to skip the currently playing song and play the next one in the queue like normal