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 · 9 comments
Open

Deno/bun support #951

alexander-potemkin opened this issue Dec 15, 2024 · 9 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?

@pelikhan
Copy link
Member

still in the radar but porting to other ecosystems is going to be a large body of work

@beingminimal
Copy link

beingminimal commented Feb 6, 2025

Hi @alexander-potemkin @pelikhan & Other Maintainers

We're very excited about GenAIScript and its potential as a next-generation library for working with generative AI. We believe it has a bright future!

We're particularly interested in contributing to Deno compatibility. We have bandwidth available and a strong team of in-house experts proficient in Deno, Node.js, and the Deno ecosystem. If anyone can provide some guidance on the specific challenges involved in achieving Deno compatibility, we're confident we can help resolve them.

To facilitate better communication and collaboration, would it be possible to create a Discord server for the project? This could be a great place to discuss development, troubleshoot issues, and share ideas.

We also wanted to mention that Node.js now has native TypeScript support, as detailed in these resources:

Deno, of course, has had first-class TypeScript and ESM support from day one.

Finally, we'd also like to suggest publishing the package on JSR (JavaScript Registry). This would greatly enhance its compatibility across all JavaScript runtimes.

We're eager to collaborate and contribute to the growth of GenAIScript. Please let us know how we can help, especially regarding Deno support.

Thank You.

@pelikhan
Copy link
Member

pelikhan commented Feb 6, 2025

Right tsx won't cut it in demo; along with a number of other depencies. To tackle this project, I am thinking about carving a subset of genaiscript built for deno. In this case, the following changes would be made:

  • genaiscript would be a library, and not an "environment" as it is today. We would still have a cli to simulate the current behavior where the library is loaded.
  • each dependency needs to be tested to see if it works in deno
  • rethink tracing to build on more standard formats?
  • rethink isolation of workloads

Just brainstorming, but my initial investigating wasn't showing good signs of being able to convert the current codebase to deno. May need a second look.

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

3 participants