Getting Started

Install with composer require <vendor>/<package> and confirm the package's service provider is auto-discovered; if not, register it in config/app.php.
Look first at the package's service provider and its schema grammar class — that is where the migration/column behavior is wired in. If the package ships a config file, publish it with php artisan vendor:publish before writing migrations.
First use case: add the package's column type or grammar behavior to a migration, run php artisan migrate, then verify the resulting table with php artisan db:table <table> (or DESCRIBE) to confirm the column is actually NULL-able in the database, not just in the migration code.

Implementation Patterns

Treat migrations as the primary interface. Define the column, chain ->nullable(), and keep the modifier order consistent across migrations so grammar output stays predictable.
Register the grammar through the package's provided service provider rather than subclassing Laravel's Schema\Grammars\Grammar yourself; this keeps you on the upgrade path.
Use Schema::table() for additive changes and keep separate migrations for adding a nullable column versus backfilling it — mixing schema and data changes in one migration makes rollback ambiguous.
In tests, prefer RefreshDatabase and assert column nullability explicitly (e.g., insert a row omitting the field) instead of relying on the migration running without error.
If the package exposes config for connection/driver behavior, set it per-connection in config/database.php rather than globally, especially in apps with multiple connections.

1.0 fixed schema grammar for nullable fields. If you previously worked around columns silently being created as NOT NULL, remove the workaround, upgrade, and re-run migrations. Existing tables are not altered by the fix — roll back and re-migrate on non-production environments, and write a corrective migration for production.
Modifier ordering matters: ->nullable() combined with ->default() or custom column types can produce different SQL depending on chain order. Keep ->nullable() immediately after the type definition and verify with php artisan migrate --pretend.
Grammar differences bite: SQLite (common in tests) and MySQL/PostgreSQL handle nullable + default combinations differently. A migration that passes on SQLite may generate different SQL in production.
Debug by dumping the generated SQL with --pretend rather than inspecting the database after the fact; nullable issues are almost always grammar-level, not data-level.
Extension point: if you need behavior beyond what the package provides, extend the package's grammar class and bind your subclass in a service provider — avoid editing vendor files, since 1.0 already changed grammar internals.
Pin the version in composer.json until you have re-run your migration suite against 1.0; this release changes schema output, so downstream snapshots or schema-dump assertions may need refreshing.