Template ENV vars in config

[zbolan]

Intent

https://github.com/adelsz/pgtyped/issues/523

In large projects and monorepos there may be multiple different databases, users, etc. This can be handled by having multiple 'config' files but this requires DB credentials to be committed into source control. Rather than being restricted to supporting only the common PG environment we can support specifying different ENV vars to use for each config.

Changes

Keeping with the "template syntax" in the config file, consumers can provide their own ENV vars to use for a config. For example -

{
  "transforms": [
    {
      "mode": "sql",
      "include": "**/*.sql",
      "emitTemplate": "{{dir}}/{{name}}.queries.ts"
    },
  ],
  "srcDir": "./src/",
  "dbUrl": "{{MY_DB_URI}}",
  "db": {
    "host": "{{MY_HOST}}",
    "port": "{{MY_PORT}}",
    "user": "{{MY_USER}}",
    "dbName": "{{DB_NAME}}",
    "password": "{{MY_DB_PASSWORD}}"
  }
}

Note

Im still doing a little more testing but wanted to open this up for review

• ✅ npm linked locally and lgtm

[zbolan]

@adelsz Im unable to add reviewers. Wondering what you think?

[adelsz]

Why not set the standard PG envs to different values for each env? Maybe I am missing some context here.

[zbolan]

Ooof this has been a while @adelsz

I think this was trying to solve for instances where theres 1 env and N databases/configs. It seems like a pretty common situation where consumers have a single application that potentially talks to multiple databases. To a lesser extent, its limiting to be constrained to use the default PG vars as other tools may be using something different

I ended up solving this by wrapping the tool in a little script that could inject the defaults

...

// .env has a my_custom_host var
dotenv.config({ path: path.join(dirName, '/.env'), debug: true });

// reassign any custom variables from `.env` to `process.env` here. Example:
process.env.PGHOST = process.env.my_custom_host;

// >>>>> this stinks
setTimeout(() => {
  import('@pgtyped/cli/lib');
});