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

Deno/bun support #951

Open
alexander-potemkin opened this issue Dec 15, 2024 · 6 comments
Open

Deno/bun support #951

alexander-potemkin opened this issue Dec 15, 2024 · 6 comments

Comments

@alexander-potemkin
Copy link

Thank you! Is there any plans / concerns on making it run under deno / bun? It will highly improve speed and, if I understand that right - offer additional sandbox abilities

Copy link

Sure! Thank you for bringing this up.

I would like to add that Deno and Bun are both gaining popularity as alternative JavaScript/TypeScript runtimes due to their speed and new features. While there is an increasing interest in making our application compatible with these platforms, we need to carefully evaluate the potential benefits and challenges associated with each:

  1. Speed Improvement: Deno and Bun are indeed faster than Node.js in many scenarios. This could lead to improved performance for users.
  2. Additional Sandbox Abilities: One of the key advantages of Deno is its built-in security model, which provides better isolation between different parts of an application. If our application can benefit from a more secure execution environment, this could be a significant enhancement.
  3. Development and Maintenance: However, supporting multiple runtimes adds complexity to development and maintenance efforts. We need to ensure that any changes made for one runtime do not introduce bugs in others.

Next Steps

It would be helpful if someone from the team can:

  1. Investigate Deno and Bun's features more thoroughly.
  2. Assess potential performance improvements.
  3. Evaluate the impact on security.
  4. Consider the long-term maintenance burden.

Once we have a clear understanding of the trade-offs, we can make an informed decision whether to prioritize Deno or Bun support or explore other options.

What are your thoughts?

generated by issue-reviewer

@pelikhan
Copy link
Member

No real issues, hasn't been a focus.

@alexander-potemkin
Copy link
Author

No real issues, hasn't been a focus.

@pelikhan , I see, thank you. I'm more interested in sandbox abilities, as I would like to expose GenAIScript functionality to a wide audience and hence need to be sure it will be properly isolated. Ben/deno seems to be pretty much built-in with those features.

So, if ben/deno are not really in focus, do you have anything related to execute untrusted code on the roadmap? If so, is there any estimate? If not, is there something you could probably advise in those regards?

Thanks in advance!

@pelikhan
Copy link
Member

Actually, there's a big one that will require some though. GenAIScript currently loads .mjs/.mts files through https://tsx.is/ which only supports node.js. I need to read more into bun to see if it can be replaced natively.

@pelikhan , I see, thank you. I'm more interested in sandbox abilities, as I would like to expose GenAIScript functionality to a wide audience and hence need to be sure it will be properly isolated. Ben/deno seems to be pretty much built-in with those features.

One way to sandbox genaiscript would be to run it in a docker without internet access. Otherwise, it's unclear how you can sandbox a JavaScript VM when importing user code.

@pelikhan
Copy link
Member

I also tried deno and it seems that it will be a lift to support that one too. Our process library execa is not compatible too so it fails early.

@alexander-potemkin
Copy link
Author

One way to sandbox genaiscript would be to run it in a docker without internet access. Otherwise, it's unclear how you can sandbox a JavaScript VM when importing user code.

I was thinking about Deno's Sandbox primarily.
Seems like execa works there and it's documented as well.

btw, is execa is a must? I mean Docker does not guarantee that the process won't leave the Docker, so it's better not to exec() anything at all. Or am I missing something?

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

No branches or pull requests

2 participants