Please describe the problem you are having in as much detail as possible:
I was trying to use member.joinedAt but typescript said it could be null which led me to try to figure out how this could ever be null.
/**
* The timestamp the member joined the guild at
* @type {?number}
*/
this.joinedTimestamp = null;


The discord API joined_at prop is not optional therefore this should never be null. Discord.js creates a null value for joinedTimestamp in the constructor of the GuildMember.

Include a reproducible code sample here, if possible:
member.joinedAt
Further details:
Is it not null even with partials?
@kyranet Ahh is this cause of partials again. Just another reason to remove partials from discord.js in my opinion. #3486
I already fixed this in #3493 (null because of partials on master). I'm not sure when it will get merged but hopefully soon ¯\_(ツ)_/¯
On stable, probably an oversight by the devs.
The reason this is null-able is because of this:
https://github.com/discordjs/discord.js/commit/13bfceb83cf771d1d56d28fd474d824f9a8884db
Completely unrelated to partials.
Could you please explain why that change was done and if that change is still relevant or needs to be reverted so I can understand it please.
The reason i am confused is why does this line exist the if check seems redundant because it will always exist as per API Docs.
if (data.joined_at) this.joinedTimestamp = new Date(data.joined_at).getTime();
What was the motivation/reasoning behind the change in that commit?
This might come as a surprise now, but Discord API docs sadly are not always accurate.
I'm sure @Lewdcario can follow up with an explanation, and I'm sure its still needed.
There is a case where you will receive a GuildMember object without a joined_at field. To be more specific, in the case you have this structure that isn't cached, and said member comes with a presence update, we will store a new GuildMember. It was a required change that happened due to the Discord API (we just noticed it at the time of that commit), and took some time to track down. It is not something we did just for the sake of making a change, that would not be productive, therefore that typing must be marked as nullable.
@Lewdcario That is a good reason to have it nullable. Closing this issue as I believe that is still true to this day. Thank you for the explanation.
Most helpful comment
There is a case where you will receive a
GuildMemberobject without ajoined_atfield. To be more specific, in the case you have this structure that isn't cached, and said member comes with a presence update, we will store a newGuildMember. It was a required change that happened due to the Discord API (we just noticed it at the time of that commit), and took some time to track down. It is not something we did just for the sake of making a change, that would not be productive, therefore that typing must be marked as nullable.