Postgrator version 8 - possible glob character break on Windows

[daniele-paltrinieri-79]

Describe the bug
After upgrading to version 8 of the library, a migration pattern created as migrationPattern = path.join(__dirname, 'migrations', '*') does not return any migrations files. Calling postgrator.getMigrations() return an empty array

Expected behavior
The migrations files will be loaded as it happens in versione 7.3

Additional context
I have done some analysis and I think the problem could happen because of these note on the glob project

Note Glob patterns should always use / as a path separator, even on Windows systems, as \ is used to escape glob characters. If you wish to use \ as a path separator instead of using it as an escape character on Windows platforms, you may set windowsPathsNoEscape:true in the options. In this mode, special glob characters cannot be escaped, making it impossible to match a literal * ? and so on in filenames.

I was able to make it works in 2 possible ways:

• add a character replace to the migration pattern, ex: migrationPattern = path.join(__dirname, 'migrations', '*').replace(/\\/g,'/')
• changing the getMigrations() function of postgrator, setting in the glob call the parameter allowWindowsEscape: false, const migrationFiles = await glob(migrationPattern, {allowWindowsEscape: false});

Both the solution solve the problem, and a filled array is returned when postgrator.getMigrations() is called.

System information

• Node v20.18.3
• Postgrator 8.0.0
• Glob 11.0.0
• Microsoft Windows 11 Pro

[rhys-vdw]

The example code in the readme does not work on windows. The glob is nice in theory, and I'm sure there was some motivation beyond just providing a directory, but maybe it could be even more generic:

const postgrator = new Postgrator({
  driver: 'pg',
  getMigrationPaths: () => getAllFilesInMyMigrationDirectory(), // returns string[]
  execQuery: (q: string) => client.query(q),
} as any)

[Jackson-Raphael]

Came to raise this myself but looks like you both beat me to it.

I worked around it using .replace(/\/g, "/") without issue. I dont think its really a 'bug' since glob mentions it clearly, just a little gotcha for windows users with no mention in the docs.

Im guessing glob motivation is related to postgrators support of js & sql migrations