fix: Do not reference __dirname if it does not exist

[PatKayongo]

The purpose of this is to fix issue #1167

For esmodules, it doesn't use __dirname to get the current module directory location, as this is not available.

[Shinigami92]

Please note that I'm in a vacation mode, I can do GitHub stuff, but I might not contribute code right now actively

[jasel-lewis]

@PatKayongo The current configuration (CommonJS) of the test cases don't like your solution, unfortunately. This SO post may be relevant (more specifically, its top-rated answer). You may simply be able to configure tsup-node (a.k.a. tsup) to write out more appropriate ESM code which may negate the need for the current solution proposed by your PR.

Update:
Yes... it looks like simply adding shims: true to the ESM config object in tsup.config.ts does the trick. Doing so adds __dirname to dist/esm/index.mjs, making it available (see screen capture below). If you have the time, would you modify your PR so that it only makes this modification to tsup.config.ts? I'd be interested if the automated PR tests begin to work again.

[jasel-lewis]

@PatKayongo What I mention in my previous post gets us over the hurdle, but only on to the next issue.

You'll notice that the loadMigrations method in the generated index.mjs file makes a decision based on the extension of each discovered migration file. If the file extension is sql, then the sqlMigration function (sqlMigration_default) is called for the migration file. Otherwise... the module code still calls on require which is not a feature of ESM. 🙄

Thankfully, the solution to this also lies within the tsup-node/tsup configuration file. We can ask it to place "banner" code at the top of the index.mjs file and in doing so, we can inject a module-compliant replacement for the require CommonJS method. Below is a screenshot of the entire tsup.config.ts file with my modifications for the previous post I made and this post.

We're then left facing one last hurdle. Now that we've injected (effectively) a require call within our ESM code, we break the build of our own code (not node-pg-migrate, but your code which is a consumer of node-pg-migrate) if your *.js migration files are kept within a project that is configured as ESM (your package.json is declared with type: "module"). The fix is simple - you just need to identify your migration files as being CommonJS by changing their file extensions from *.js to *.cjs.

Note: This all just seems..... like a very hacky fix. While it is safe enough (in my opinion) for a bug fix under v7.x of node-pg-migrate, the core of the issue lies in how the TypeScript is written since esbuild (by way of tsup-node/tsup) is employed to transpile the TypeScript into both CommonJS and ESM versions of the code.

Research: My findings come primarily from this thread and, specifically, this post.

[Shinigami92]

I plan to go esm first in v8 and drop cjs support in v9
But this could take nearly a year until v9 is released, so the current tries are 100% welcome 🚀

[jasel-lewis]

I plan to go esm first in v8 and drop cjs support in v9 But this could take nearly a year until v9 is released, so the current tries are 100% welcome 🚀

@Shinigami92 That is wonderful news! For the time being, the changes I've posted above seem to take care of the issue. I cloned and tested locally and can confirm that the JavaScript migration files (if named *.cjs) can be ingested and run by the node-pg-migrate package consumed from within a type: "module" NodeJS project. I have not tested SQL migration files, however, as that is not my current use case. I may be able to look into that in the coming days. For now, however, I'd respectfully request that we get the tsup.config.ts fixes implemented as a hotfix to the v7 code base. @PatKayongo already has a PR out there for this fix, but it needs different direction since the issue (for JavaScript migration files) is more appropriately addressed (in whole) within tsup.config.ts and I don't want to step on his toes.

[Shinigami92]

if named ´*.cjs´

This is what I meant with v8 🙂