rysana-ai / bundown

Bundown is a fast all-in-one Markdown runtime and bundler, built on Bun.

Lusat

AI Superpowers for your apps. Install:

npm i lusat

Lusat is Rysana's open source tookit for building powerful, secure, and intuitive AI-augmented natural language applications for the web. This is the TypeScript/JavaScript version of the Lusat toolkit.

---

Log -- Website -- Docs -- Rysana

---

Documentation

For details on how to build with Lusat, see the Lusat documentation.

Installation

You can install lusat with npm, pnpm, or yarn, and you can build it from source with the build script.

npm	pnpm	yarn
npm i lusat	pnpm i lusat	yarn add lusat

API Platform

If you want to use the Rysana AI platform, you will need to create an account and create a project. You will need the your API key to use the Rysana AI platform.

# .env
RYSANA_API_KEY=your-api-key

Imports

Currently, Lusat for TS/JS is bundled into a single lusat package on NPM.

You can import core functionality without including platform-specific code from lusat:

import { action, app } from 'lusat'

You can import platform-specific code from independently bundled files, e.g. for React:

import { useHotkey } from 'lusat/ui/react'

or for third-party adapters:

import { gptFunctions } from 'lusat/adapters/openai'

bundown's Issues

Source mapping, block step execution & line step execution.

I think it would be relevant to have some form of source mapping, so that errors in the execution of the generated script can be traced back to the original markdown file.

Two more nice to have in my opinion are block stepping and line stepping the execution of the file. This would give the user a chance to review what is going to be run, which is important if we are just taking and trusting a random file from the internet.

It would also be nice because I am integrating bundown with ollama and some self-hosted model to comment on the nature of the code which is going to execute, so that the inexperienced user can have a better-than-0 context about the operations which are going to be performed, if they are potentially dangerous or at the very least on what to expect.

Please, let me know what you think about these features and if they are desirable in bundown mainline.

Tabs seem to break box-drawing in print mode

I was playing around with #9 locally today and it seemed that a tab for indentation in a code block caused the box drawing in print mode to miscalculate the width of that line, forcing the right border of the box onto a new line in my terminal.

We should probably preprocess tabs out of code blocks and replace them with a couple spaces each or something before printing happens.

About the scope of the roadmap

I have few comments about the roadmap, and since discussions are not enabled in this repo, I will write them down here.

We are using markdown tags for bash and other shell variants to mark sections to be executed by the new bun shell syntax.

However, those are neither bash nor zsh.
For example, things like for cycles do not work, and the syntax is somewhat divergent from any specific shell, favoring the integration with js/ts. This design decision/limitation is totally fine within the scope of bun shell, but considering that you envision support for multiple languages as part of the roadmap, this would leave shell scripting far behind in terms of compatibility.

In my opinion, the only way to have a true portable bash would be to compile it for webassembly, and pack it with the application, or to manually exec it hoping the system has minimal support for it, which was one of the main reasons why bun shell was made in the first place.