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

[PROPOSAL] LLRT compatibility #883

Open
paul-uz opened this issue Oct 8, 2024 · 5 comments
Open

[PROPOSAL] LLRT compatibility #883

paul-uz opened this issue Oct 8, 2024 · 5 comments
Labels
🧗 enhancement New feature or request

Comments

@paul-uz
Copy link

paul-uz commented Oct 8, 2024

I'd like to suggest making this package compatible with the AWS LLTR - https://github.com/awslabs/llrt

This cut down Node runtime is super fast, at the cost of it not having all the Node APIs.

It does not contain the tty module, which is required by the debug dependency in this package.

Could you please consider making this library compitable, as there is no "AWS SDK" Opensearch client, as this one exists, and I believe OS is an AWS product anyway. Would be nice to use this with the LLRT.

@dblock
Copy link
Member

dblock commented Oct 8, 2024

What would it take to make this package compatible with llrt? PRs welcome.

believe OS is an AWS product anyway

This is not the case, especially since September, OpenSearch is part of the Linux Foundation (https://foundation.opensearch.org/).

@dblock dblock added 🧗 enhancement New feature or request and removed untriaged labels Oct 8, 2024
@paul-uz
Copy link
Author

paul-uz commented Oct 8, 2024

What would it take to make this package compatible with llrt? PRs welcome.

Probably a move to ESM as there is an issue when the code i bundled via ESBuild and how the debug package is included. As well as no tty module on LLRT. Also, if this package uses http that needs to be moved to fetch

@dblock
Copy link
Member

dblock commented Oct 8, 2024

@paul-uz We would like many of these things. We've done some serious surgery as part of #803 and would like more. Things like moving from http to fetch is likely uncontroversial (@nhtruong can comment), same for the rest. Try to pick one up?

@paul-uz
Copy link
Author

paul-uz commented Oct 14, 2024

@paul-uz We would like many of these things. We've done some serious surgery as part of #803 and would like more. Things like moving from http to fetch is likely uncontroversial (@nhtruong can comment), same for the rest. Try to pick one up?

I'd love to have a go at implementing one of these changes, but in all honesty, it's probably a bit beyond me currently. I am fairly competent with JS/TS, Node etc but when it comes to some of these libraries, I'd need to figure out how they are pieced together first :)

http to fetch might be one I could attempt.

@dblock
Copy link
Member

dblock commented Oct 14, 2024

http to fetch might be one I could attempt.

Sounds great. A pure replacement would be a great start, and we should then talk about something pluggable in the PR.

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