Bug fix: unable to run migration from compiled files

[lelinhtinh]

I wrote migration using ts but when building and running on production environment, compiled js files have module not found error. The reason is because the extension is fixed as .ts.
Realizing that nodejs and typescript do not require extension so I removed them in this PR.

[ilovepixelart]

Also just a general question you are the second person who compiles migrations, what is the use-case for that?
The whole idea of the package that you put your migrations outside of source then transpile and run them on demand
Check full example here: https://github.com/ilovepixelart/ts-express-swc

Basically you expanding on this idea that was recently added, now I'm thinking this was a mistake to add in the first place)
#365

[lelinhtinh]

Also just a general question you are the second person who compiles migrations, what is the use-case for that? The whole idea of the package that you put your migrations outside of source then transpile and run them on demand Check full example here: ilovepixelart/ts-express-swc

Basically you expanding on this idea that was recently added, now I'm thinking this was a mistake to add in the first place) #365

I build migrations with source code, and run it using nodejs, no tsc.

[ilovepixelart]

Also just a general question you are the second person who compiles migrations, what is the use-case for that? The whole idea of the package that you put your migrations outside of source then transpile and run them on demand Check full example here: ilovepixelart/ts-express-swc
Basically you expanding on this idea that was recently added, now I'm thinking this was a mistake to add in the first place) #365

I build migrations with source code, and run it using nodejs, no tsc.

Yeah but why you do it this way? Is there a reason for it? Wait you don't use typescript, in your project?

[ilovepixelart]

We also have programmatic approach of running migrations
https://github.com/ilovepixelart/ts-migrate-mongoose/tree/main/examples
Both programmatic mode and CLI will transpile your migrations on the fly without need to compile, as long as they written in Typescript and your project should use CommonJS compile target

[lelinhtinh]

Also just a general question you are the second person who compiles migrations, what is the use-case for that? The whole idea of the package that you put your migrations outside of source then transpile and run them on demand Check full example here: ilovepixelart/ts-express-swc
Basically you expanding on this idea that was recently added, now I'm thinking this was a mistake to add in the first place) #365

I build migrations with source code, and run it using nodejs, no tsc.

Yeah but why you do it this way? Is there a reason for it? Wait you don't use typescript?

Because if the migration contains other dependencies, for example lodash. Then node_modules must be kept in the build, which is not very reasonable.

[ilovepixelart]

Also just a general question you are the second person who compiles migrations, what is the use-case for that? The whole idea of the package that you put your migrations outside of source then transpile and run them on demand Check full example here: ilovepixelart/ts-express-swc
Basically you expanding on this idea that was recently added, now I'm thinking this was a mistake to add in the first place) #365

I build migrations with source code, and run it using nodejs, no tsc.

Yeah but why you do it this way? Is there a reason for it? Wait you don't use typescript?

Because if the migration contains other dependencies, for example lodash. Then node_modules must be kept in the build, which is not very reasonable.

Whether or not you need node_modules, depends on how you build your stuff, in your case I suspect you bundle your code if you say you don't need node_modules after your build process. Look I'm genuinely interested in your build process now, so can you explain to me what are the benefits for you of bundling code on backend?
The only thing I can can think off, is I/O lookups for files but in that case you should bundle into one file instead of multiple. But if you run your migration files they are stand alone...
Also can you tell me what tool do you use to build?
Just in case you use esbuild as your bundler: https://github.com/ilovepixelart/ts-express-esbuild

[lelinhtinh]

For small applications, bundling is useful using tree-shaking, some tools like ncc, webpack supports this. For applications built with nestjs I still keep node_modules, because its dependencies often cause errors.

[ilovepixelart]

Yeah exactly what I thought, I guess ncc is a good example surprisingly built on top of web-pack (thought it was dead), but at this point you do basically serverless.

Ok now lets look at this from standpoint of the lib, do we really need all these after compilation use cases
When the whole point of lib is on demand transpile and run from TS files
Lets say you bundle your stuff to js and then run it what is the purpose of the lib I think at this stage we loosing the plot)

What if we improve documentation instead, and describe the intended use

[lelinhtinh]

If the library can accommodate both usages, with just a few minor changes, that's even better.

[ilovepixelart]

Your tests are hanging indefinitely, probably you are not closing migrator or some dangling connections

[lelinhtinh]

Your tests are hanging indefinitely, probably you are not closing migrator or some dangling connections

The connection in getModels is causing this issue

ts-migrate-mongoose/examples/config-file-usage/models/index.ts

Line 12 in ce0e478

await mongoose.connect(process.env.MIGRATE_MONGO_URI ?? 'mongodb://localhost/my-db', mongooseOptions)

[ilovepixelart]

Lets update docs about connection passed as first prop in migration functions

[ilovepixelart]

Released in: https://github.com/ilovepixelart/ts-migrate-mongoose/releases/tag/v3.8.8

[bensquire]

Thanks for this. Just an FYI we also run migrations once they've been compiled into JS.