Feature: Support ES Module Pattern
JDThralls opened this issue · 10 comments
Is your feature request related to a problem? Please describe.
Currently, it is not possible to use ES modules with this library, which is an issue as I am using ES modules in a lot of projects.
E.g. I have projects where the database and data source files are in a dependency of the services to allow for a shared code base. They are organized in ES Modules. The usage of these modules is not supported in commonJS projects, giving errors when trying to use the seeding feature.
Describe the solution you'd like
Add support for ES modules by switching from commonJS module import to ESNext module import.
This is just a matter of aligning the module import with the library configuration in the tsconfig.json.
Simply switching the configuration from "module": "commonjs", to "module": "ESNext", will do the trick.
Describe alternatives you've considered
The alternative solution is that everyone using this library would be required to be writing their code as commonjs-compatible, even though the library already uses ESNext lib components.
Hey @JDThralls ✌️,
thanks for the contribution 😊. Contributions are generally very welcome. But I think we should keep backwards compatibility for commonjs projects. Therefore we should use e.g. rollup for bundling instead of using typescript.
If you like, you can change the implementation to rollup as a bundler. Otherwise I'll take care of it because I already have quite a bit of experience with rollup.
Hi @tada5hi ✌️
Thanks for the quick reply.
I have not used rollup yet but that sounds like a great idea. Might be a good idea to do that with Locter first as that is the component that is used to load DataSource and seeder files if I see that correctly.
I might have opened this issue on the wrong repository then. 😅
I am looking into rollup now, if you have time it would be great if you could do it. 😉
@JDThralls your welcome 😊 .
Yes, I will have to start with Locter. Your assumption was correct. It affects both projects, so your approach to mention it in both repositories was absolutely right.
I can devote myself to that ✌️
PS: If you have time and muse, I would be happy if you could take a look at routup and give me feedback on it.
It is a lightweight and extendable http interface based routing framework written TypeScript.
Bad news for now 😔
The refactoring of related libraries like rapiq & locter were not "the" problem.
But in case of the typeorm-extension lib it was a different story.
One of the issues was, that i couldn't rely on a bundler (rollup, esbuild, etc.).
The reason for that was that i had to compile and bundle the whole code base and the cli seperatly ( different entrypoints ).
This caused the problem that i could not access the same data-source instance from the cli and from the code base, due different absolut paths.
Therefore, i tried to only transpile the code to cjs and esm with different output directories.
That seemed to be the solution at first sight. However, I now have the problem that esm does not allow directory imports.
That's the current status. I've also opened a new branch for it, if you want to take a look ✌️.
Hey @tada5hi ,
sorry for being MIA for a few days.
I switched my projects back to commonJS again for now as support in other libraries seems still somewhat scarce.
I only took a quick glance at the branch, will look into it more when I have a bit more time. 🙂
@JDThralls no problem at all 😊.
I'm sorry you had to switch back to commonjs,
but i think it still will take some time until the esm support is no longer experimental for node.js and most libraries are either polymorphic for commonjs and esm or migrated to pure esm.
Nevertheless, I would like to change soon and make my contribution to that goal.
What might be a viable solution would be to outsource the sub modules (instance-management, seeding, database-management) as external libraries, than it would be no longer a problem that the module cache path (https://nodejs.org/api/modules.html#caching) for the bundled cli and the main file (for imports) is not the same.
@JDThralls esm support is coming soon 🎆 . Besides, ts-node will no longer be necessary, because ts and esm will be transpiled on the fly if necessary. ^^
@JDThralls i have released 3.0.0-alpha.5. few days ago, maybe you wanna try it out.
Not opening that again, I simply sadly had not a lot of time to look into anything, work has been eating up all my time in the past like 10 months.
I'm looking forward to esm support though, thank you. 🎆 🙂
And I hope I can contribute a bit more as this is a really great project. ❤️