Confusing installation steps

[vanpet]

Trying to use this package, I'm lost in the installation phase, between copy pasting files and getting circular dependancies in the deps file.

I think the installation readme should be more straightforward.

[KyleJune]

Right now the setup is basically copying the example's migrate.ts file.

The current installation path is shown further down in the Postgres CLI section. I don't specify how to earlier in the CLI section.

However the example uses relative paths for the imports. They need to be changed to urls or jsr. If using jsr, I should make the import path "jsr:@udibo/[email protected]".

[kerimhudson]

Something I stumbled across when using this is that the use of the load step isn't really covered in the getting started. So when you're running apply, you just keep getting 0 migrations, which is slightly confusing.

I guess the steps should be:

1. Init
2. Create a migration
3. Load the migration
4. Apply the migration

If I understand how this works correctly? That seemed to work for me.

[KyleJune]

Something I stumbled across when using this is that the use of the load step isn't really covered in the getting started. So when you're running apply, you just keep getting 0 migrations, which is slightly confusing.

I guess the steps should be:

1. Init

2. Create a migration

3. Load the migration

4. Apply the migration

If I understand how this works correctly? That seemed to work for me.

Thanks for that feedback. I think I might just get rid of the init and load steps in the next release. Currently init is used to create the table for tracking migrations, load is used for checking the folder for any new/changed migrations, then all the other commands just go by what is in the table rather than checking the migrations directory. So currently, you must load the migrations before applying.

[kerimhudson]

Something I stumbled across when using this is that the use of the load step isn't really covered in the getting started. So when you're running apply, you just keep getting 0 migrations, which is slightly confusing.
I guess the steps should be:

1. Init

2. Create a migration

3. Load the migration

4. Apply the migration

If I understand how this works correctly? That seemed to work for me.

Thanks for that feedback. I think I might just get rid of the init and load steps in the next release. Currently init is used to create the table for tracking migrations, load is used for checking the folder for any new/changed migrations, then all the other commands just go by what is in the table rather than checking the migrations directory. So currently, you must load the migrations before applying.

I think that would definitely give it a bit more of an automatic feeling, similar to how prisma does it.

Personally, I'm a fan of an init step because it makes clear for the user of the CLI that something is going to happen. I think some people might frown on the idea of a table being generated without being informed.

I wonder if to make it feel a bit more magical you could have the init command also make the migrationsDir if it doesn't exist, so that it's very clear where the migrations need to go. And then just perhaps print out some helpful lines in the console like:

To get started, add in your first migration and run "migrate apply".

Or combining both:

Database has been initialized with a new migration table.
To get started, add in your first migration and run "migrate apply"