search

Theodo-UK / nestjs-admin

A generic administration interface for TypeORM entities
https://nestjs-admin.com
MIT License
536 stars 60 forks source link

Support custom config on nestjs-admin CLI #148

Open therealedsheenan opened 4 years ago

therealedsheenan commented 4 years ago

Summary

It would be nice to have a support for a custom ormconfig.js when generating an admin user via CLI. Something like: npx nestjs-admin createAdminUser --config=<CUSTOM_PATH>/config.js.

Current workaround

I needed to copy my custom ormconfig.js file to the root of the codebase and fire up the cli command from there. (npx nestjs-admin createAdminUser).

ruslanchek commented 4 years ago

Lucky you! I'm unable to start it at all, too many bugs and nothing works from the readme. Literally nothing works.

TheBigBadBunce commented 4 years ago

Sounds good. Added to the todo list! @ruslanchek - Can you share some of the bugs you've encountered? It's about time we squashed a few 😅

williamdclt commented 4 years ago

It is indeed an important feature.

TL;DR: I'm pondering how to go about it but it's on the roadmap.
In the meanwhile, a workaround is to set environment variables (setting TYPEORM_URL should be enough) while running the command. For example:

TYPEORM_URL=postgres://myuser:mypassword@myhost:5432/mydatabase npx nestjs-admin createAdminUser

At the moment, the nestjs-admin script works if you use the standard conventions of TypeOrm (either top-level ormconfig.* or env vars, hardcoded config in TypeOrm.forRoot can't be supported). And even then, we'll always use the default database connection.

I am torn between several options (thinking out loud here):

  1. providing CLI options to specify your config file and the database connection you want to use
    • Good: it's fairly easy to use
    • Bad: this will be a bit tricky to implement. We'll need to mimic TypeOrm's --config param, probably using ConnectionOptionsReader which isn't documented.
    • Bad: this will probably need non-trivial maintainance
  2. Always prompting for a database URL (or maybe only if we can't detect a TypeOrm config automatically)
    • Good: will always work, easy to maintain, less dependency on the TypeOrm config loading
    • Bad: less-than-ideal UX
  3. Getting rid of this createAdminUser altogether, adding documentation on how to roll your own to fit your particular needs
    • Good: less maintainance cost, more flexible
    • Bad: significantly harder to get started with the lib

Given that this is a script meant to be ran once per environment (to create an initial AdminUser, which can then create more through the admin interface), I'm not super happy about maintainance burden. That being said, it's one of the first interactions of the user with this library and I want it to be a good experience...

All in all, I'd probably go with the first option. I will post updates here once this is done (if anybody wants to work on this please do and announce it here)