Idea: provide a way to customize generated migration and entity naming strategy

[cyrilchapon]

Is your feature request related to a problem? Please describe.
Currently, migrations are generated with upper case (just like migration class name).
This can cause problems in some systems; and is a controversed strategy (not going into details here; trying not to be polemic)

Describe the solution you'd like
It would be a good thing to have the ability to customize the file-naming-strategy; just like config allows namingStrategy: UnderscoreNamingStrategy (for table names I assume; just discovered this).

Maybe :

{
    entityFileNamingStrategy: KebabNamingStrategy,
    migrations: {
      migrationFileNamingStrategy: KebabNamingStrategy
    }
}

Which would generate migration-20200402211502.ts instead of Migration20200402211502.ts

EDIT: Maybe along with some prefix / suffix customization; to be able to add things like .model.ts automatically for entities.

Describe alternatives you've considered

1. Accepting the fact to have a single CamelCased files directory in my codebase...
2. Renaming each migration each time I generate one, and tell my developers to do so

Additional context

To expand on kebab versus camel. (still avoiding debate, just to say some have reasons to prefer kebab-everywhere, and that it's a decent use-case)

try this

aFile.js

const a = {
  b: 'foo'
}
module.exports = a

another-one.js

const aa = require('./aFile')
const ab = require('./afile')

console.log(aa === ab)

Now retry this on windows, mac, and ubuntu.
It might give different results.

Also :

• Another argument https://nodejs.org/api/modules.html#modules_folders_as_modules
• Another one https://google.github.io/styleguide/jsguide.html#file-name

[B4nan]

We can have a customizable callback to generate the name, why not, just keep in mind that those file names are used for ordering.

Btw the example with windows issues and LC vs UC is kinda invalid, this is about migrations, they will be in a specific folder, all the content is generated, even if future ORM version would change the case, you still have the timestamp suffix.

But what I can understand is that you simply want to have consistent file names across your app, so again, why not :]

EDIT: Maybe along with some prefix / suffix customization; to be able to add things like .model.ts automatically for entities.

Do not mix this with NamingStrategy, that is more complex than just camelCase/PascalCase/snake_case, so it won't fit here - but the customizable callback for migration file name will be just fine. Also note that you can have any entity suffix, including .model.ts, by default. And this is actually something you can customize already, via the NamingStrategy:

https://mikro-orm.io/docs/defining-entities#entity-file-names
https://mikro-orm.io/docs/naming-strategy/#namingstrategygetclassnamefile-string-separator-string-string

[cyrilchapon]

@B4nan ,

Callbacks sounds good. About ordering, I'm pretty used to umzug through sequelize-cli and even an own cross-db implementation; the best I can think of is, maybe, timestamp-first (and maybe .migration.ts suffix); but this is all opinions. Upvote for the callback.

I'm pretty much starting with TS, and mikro-orm; and I have to say I'm seduced :)

[cyrilchapon]

Hum; well about entities and NamingStrategy, I hadn't read that much the API. It's pretty great.

Thinking of it... you argue

Do not mix this with NamingStrategy, that is more complex than just camelCase/PascalCase/snake_case, so it won't fit here

As far as I can read, this is about Class/prop-to-db-Table/col and the reverse operation.
I think the migrationOption API can be improved in the same direction. I mean, there is (apparently) a need to have a code-to-filename strategy; and there is already a simple filename-to-code strategy (with pattern option). Am I wrong ? :D

[B4nan]

Closing as implemented in v4 via bdc60be (will be part of 4.0.0-alpha.4), see #527 more more updates on that.