Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESM support #66

Open
lorefnon opened this issue Dec 12, 2022 · 4 comments
Open

ESM support #66

lorefnon opened this issue Dec 12, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@lorefnon
Copy link
Contributor

Would you be open to a PR that exposes es modules in the deployed package as .mjs artifacts ?

This doesn't need to be a breaking change but likely all drivers won't be importable as es modules so only subset of databases would be available through esm.

I am trying to migrate a project to esm and currently ts-sql-query is one of the few dependencies that aren't exposed as esm.

@juanluispaz
Copy link
Owner

Good, I'm going to investigate how to implement it. If you can provide some hints on this I will appreciate.

@lorefnon
Copy link
Contributor Author

lorefnon commented Dec 13, 2022

I was originally thinking I could just add a tsconfig.esm.json which generates modules and have those files alongside commonjs with mjs extension.

However, it looks like tsc does not yet allow specifying an extension, and in esm (when a bundler is not involved) imports must also have the extension. I have an early setup with babel that rewrites the imports - I'll test out what all drivers can be expected to work and update in some time.

Let me know if you have any concerns with the approach.

@lorefnon
Copy link
Contributor Author

The linked pr does what it was originally intended to do.

However, I found that node's commonjs->esm interop also works well enough for my project. It was sufficient to just ensure that all the imports to ts-sql-query had an extension - and with the --experimental-specifier-resolution=node option recently added by node even that is optional.

So unless long term you plan to migrate the package to esm, we can close that pr.

@juanluispaz
Copy link
Owner

Then, I will prefer to archive the PR for now, I will continue investigating this topic more in deep taking as reference your PR. I'm afraid, depending how it is implemented, it could require a major release.

Regarding the future plan, I would like to add support to ESM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants