I have the case, I updated from 5.7 to 5.8 by following the upgrade guide in a WIP project.

By doing this all my packages have updated but not the migrations in the project's database folder.

The error happens when running php artisan migrate:fresh, packages "up to date migrations" have bigInteger but not the migrations in the project.

I fix it in the project folder, but I think that it's need to be documented.

@sebastienheyd like @laurencei said, this only affects new migrations. It doesn't needs to be in the upgrade guide. It's in the changelog if you want to reference any changes to the skeleton.

IMO there should be an .env option to keep the legacy $table->increments('id'); inside new migration files generated by Artisan, because this can get annoying really quickly with foreign keys.

@laurencei and @driesvints, it looks like it is a breaking change as @sebastienheyd said. Changes on migration stubs is not breaking but a little change in create_users_table migration is breaking. It can break all packages that have migrations containing foreign keys to user_id. An example which shows causes of this change would be that issue.

@yusufkandemir - its not breaking to an existing application. It is a change of behavior for new applications. But that's really the package incorrectly assuming it thought it knew what the user_id will always be, which is a mistake.

There has always been a chance the user_id might be a string (UUID) or a bigInt. There was never a guarantee in life that it would always be just an integer. If a package wants to force a foreign relationship onto a column it does not own, then it should be configurable. There's really no other option here, because regardless of defaults, the user table is outside of anyone's control except the developer doing it.

If someone runs into this, they can change their own user table to just use integer if they really want.

@laurencei

There was never a guarantee in life that it would always be just an integer

This is true, but it doesn't justify that the change isn't a BC.

BC is

A change in one part of a software system that potentially causes other components to fail.

Which applies here.

Nevertheless it's my turn to fix the package.

@fulopattila122 you can't claim BC break in the skeleton. This file could have been modified by any Laravel user at any moment and would have broken your package (for them) already. The change in the skeleton just made abundantly clear that hooking a foreign key into a database you don't own is setting yourself for broken apps.
Yes, you can try to argue that 99% of Laravel users don't change this file, but that's not a technical reference.
Any user at any moment can modify any Laravel skeleton file. You either hook yourself into the Laravel Framework or you make your package configurable to follow the user's skeleton.