zapatos generation produces no output

[skeet70]

I've followed the installation and configuration docs, but when I try to generate my schema, I get no output. I've tried both programmatic and the CLI generation tools. If any of the environment variables are missing, I get an error reflecting that. When everything is present however, I simply get no output.

Versions:

{
    "zapatos": "^5.0.0",
    "pg": "^7.18.0",
    "@types/pg": "^8.6.4",
}

CLI

zapatosconfig.json:

 {
    "db": {
        "host": "{{DB_URL}}",
        "user": "{{DB_USER}}",
        "password": "{{DB_PASSWORD}}",
        "database": "{{DB_NAME}}"
    },
    "progressListener": true
}

Output

λ  env $(cat .env.local) npx zapatos
λ

Programmatic

tsconfig.json:

{
    "compilerOptions": {
        "strict": true,
        "sourceMap": true,
        "noImplicitReturns": true,
        "noUnusedParameters": true,
        "noEmitOnError": true,
        "noUnusedLocals": true,
        "declaration": false,
        "jsx": "react",
        "target": "ES6",
        "module": "commonjs",
        "moduleResolution": "node",
        "resolveJsonModule": true,
        "pretty": true,
        "removeComments": true
    },
    "files": ["global.d.ts"],
    "include": ["src", "src/server/lib/.ts"],
    "exclude": ["node_modules"]
}

package.json:

"generateSchema": "yarn run ts-node --files -r dotenv/config generateSchema.ts "

generateSchema.ts:

import * as zg from "zapatos/generate";

const zapCfg: zg.Config = {
    db: {
        host: process.env.DB_URL,
        user: process.env.DB_USER,
        password: process.env.DB_PASSWORD,
        database: process.env.DB_NAME,
        ssl: process.env.DB_SSL === "true",
    },
    progressListener: true,
};

console.log("calling generate");
(async () => {
    await zg.generate(zapCfg);
    console.log("generate done");
})().catch((e) => {
    console.log(e);
});

Output

λ  yarn generateSchema
yarn run v1.22.17
$ yarn run ts-node --files -r dotenv/config generateSchema.ts
$ node_modules/.bin/ts-node --files -r dotenv/config generateSchema.ts
calling generate
Done in 5.17s.

Either way no files are generated and no console or progress output is available. I must be missing something really basic here, but I'm not sure what it is. I've tried several variations of commands to run the programmatic version as well, all with the same result.

[skeet70]

I enabled debugListener and ran it again and got:

λ  env $(cat .env.local) npx zapatos
>>> query 0 >>>
SELECT
table_name AS name
, lower(table_name) AS lname  -- using a case-insensitive sort, but you can't order by a function in a UNION query
, CASE table_type WHEN 'VIEW' THEN 'view' WHEN 'FOREIGN' THEN 'fdw' ELSE 'table' END AS type
, CASE WHEN is_insertable_into = 'YES' THEN true ELSE false END AS insertable
FROM information_schema.tables
WHERE table_schema = $1 AND table_type != 'LOCAL TEMPORARY'UNION ALLSELECT
matviewname AS name
, lower(matviewname) AS lname
, 'mview'::text AS type
, false AS insertable
FROM pg_catalog.pg_matviews
WHERE schemaname = $1ORDER BY lname, name
+ ["configbroker"]

λ 

I looked in the source code for tsForConfig and saw that's where this query text is being generated. I tried wrapping the pool.query(query) call with a more direct catch/then, as well as printing out the exit code to make sure I wasn't somehow missing a error message. It had the same silent failure problem that the whole project seemed to.

To me this meant the problem was with pg, not with your code (though maybe with the peer version required) so I updated to the most current version of pg and ran again, which successfully progressed functioned as expected.

I'm not going to look into this any more, since the updated version of pg doesn't seem to conflict with my existing code, but the next step would be to test with bumped versions of pg until finding one that actually works and updating the peer requirement for it.

[jawj]

Thanks for the report. Seems a bit surprising, since 7.18.0 is not that old.

Any chance it's related to this? https://github.com/brianc/node-postgres/issues/2085

[skeet70]

It's possible, but I wasn't getting any errors anywhere, so it's unlikely. If it was (since the problem seemed narrowed down to the pg call), then the driver would've been eating the exception.

[jawj]

I'm going to close this for now, as it's gone away for you and I've never seen nor had other reports of it. I'll reopen if anyone else reports it, of course.