New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(migrations): add support for custom migration names #4250
feat(migrations): add support for custom migration names #4250
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
@@ -452,7 +452,7 @@ export type MigrationsOptions = { | |||
snapshotName?: string; | |||
emit?: 'js' | 'ts' | 'cjs'; | |||
generator?: Constructor<IMigrationGenerator>; | |||
fileName?: (timestamp: string) => string; | |||
fileName?: (timestamp: string, name?: string) => string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the default implementation should respect the name
out of box
fileName: (timestamp: string) => `Migration${timestamp}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, I wasn't aware that the update was necessary. Thank you for pointing out this. as for the default implementation, would it suffice to simply add the parameter, or should we consider a different approach, such as using Migration${timestamp}${name}
? Let me know your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd go with Migration${timestamp}${name ? '_' + name : ''}
and dont forget to update the docs |
docs/docs/migrations.md
Outdated
> To specify a name for your migration file, we can use `npx mikro-orm migration:create --name=newName` | ||
|
||
You can customize the naming convention for your migration file by utilizing the `fileName` callback and overriding its default behavior. | ||
```sh | ||
migrations: { | ||
fileName: (time, name) =>`Migration-${time}+${name}` | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should have its own section, its not just about "Using via CLI", should be more like "using custom migration names"
also, the parameter is not time
but timestamp
, we should have type hints in there for both, and the language is not sh
but ts
, plus bad indent. in this example, we should also throw in case the name is not provided.
migrations: {
fileName: (timestamp: string, name?: string) => {
if (!name) {
throw new Error('Specify migration name via `mikro-orm migration:create --name=...`');
}
return `Migration${timestamp}_${name}`;
},
},
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for your input! I have added a new section. Please let me know if I have missed anything else or if you think additional information should be included.
In terms of naming conventions, throwing an error may not always be necessary and will depend on the user's specific case. If the user intends to always specify a name in the migration file (which I personally recommend), then throwing an error is necessary. However, if the user only wants to customize the file naming convention and check if a name has been provided, they can do so without throwing an error. I included two cases in the doc as well
f9ca5e3
to
997745f
Compare
997745f
to
660749e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the code is ok now, lets please try to improve the docs, now its more like few disconnected notes.
if you struggle with this, no worries, i can rewrite it myself if you want
Thanks, Martin! I made the updates to the document based on your feedback, but I'm afraid I might have missed other important points. I would appreciate it if you could share your thoughts on the document and feel free to make any necessary changes. |
eb663a9
to
412a2f9
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #4250 +/- ##
=======================================
Coverage 99.70% 99.70%
=======================================
Files 214 214
Lines 13965 13986 +21
Branches 3277 3283 +6
=======================================
+ Hits 13924 13945 +21
Misses 40 40
Partials 1 1
... and 8 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
--name
option to migration:create
commandThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
improved the docs a bit
) This PR adds a new option to the `migrations:create` command that allows developers to specify custom names for migration files. Previously, the migration files were automatically named based on the current timestamp, but with this new option, developers can now give the migration file a more descriptive name that is easier to understand and manage. This feature was inspired by the functionality in Laravel and Ruby on Rails, and I believe it will bring many benefits, including improved readability and organization of migration files. I created a discussion before on this: mikro-orm#3987 --------- Co-authored-by: Martin Adámek <banan23@gmail.com>
This PR adds a new option to the
migrations:create
command that allows developers to specify custom names for migration files. Previously, the migration files were automatically named based on the current timestamp, but with this new option, developers can now give the migration file a more descriptive name that is easier to understand and manage.This feature was inspired by the functionality in Laravel and Ruby on Rails, and I believe it will bring many benefits, including improved readability and organization of migration files.
I created a discussion before on this: #3987