Contributing

Thank you for taking the time to contribute and help TableX to grow and evolve!.

All contributions are very welcomed, starting from fixing typos or reporting issues to bug fixes and pushing cool features.

Whatever the level of your expertise, you will definitely find some issue that suites you best. ( Check out the issues section ).

Codebase Overview

TableX is a Tauri app which uses React for the Frontend and Rust as the Backend.

During release builds, we bundle MetaX with the final build.

TableX is a monorepo which contains:

• apps/core: containing the desktop application core logic.
• apps/web: landing page for TableX.
• crates: some of TableX’s logic splitted into small crates for better organization.
• packages: shared package between core and web.
• scripts: some useful scripts for setting up some things in github actions, your probably won’t need to touch this.

Inside the package.json file, you will find all the scripts you need regarding linting, starting dev servers, building, etc.

Local development

Let’s get you started playing around with TableX locally.

Prerequisites

• Cargo 1.81.0 or later
• Bun 1.1.27 or later

Caution

some previous versions of the previously mentioned requirements may still work fine, but no guarantee.

Getting Started

1. Clone the repo:

   git clone https://github.com/kareemmahlees/tablex.git --depth=1

2. Install necessary frontend dependencies:

   bun install

3. Install husky git hooks:

   bunx husky install

   This runs some checks and linting before you commit to ensure good code quality.

and you are good to go 💫, you can start your development server by running:

bun tauri:dev

Caution

This will start a dev server, but will also install cargo dependencies before that, which may require you to install some system dependencies, such as: libsoup, libjavascriptcoregtk, libgtk, libwebkit2gtk. Exact installation instructions will vary by platform.

Want to test how your modification will look like at the final executable? run this:

bun tauri:debug

this will create a debug build/executable, which you don’t have to install in order to see your changes, just run the file located under ./target/debug/tablex 🥳.

If you want to create a release build, run the following:

bun tauri:build

The same steps are applied as the debug build if you want to run the release build without installing it, just make sure to replace target\debug with target\release.

If you are interested in playing around with the website, run the following:

bun astro:dev

Developing the CLI

We use Clap as the CLI parser and not the tauri integration solely because clap is more verbose.

developing the CLI doesn’t differ that much from running the normal application, you just create a debug or a release build and run the produced executable with the args/flags of your choice.

For example:

$ ./target/{release,debug}/tablex {{ARGS_OR_FLAGS_HERE}}

If you wish to run in dev mode, make sure to run the following command with the exact formula:

$ bun tauri:dev -- -- -- [CONN_NAME] [FLAGS]

Guidelines

TableX adheres to some development guidelines to ensure that the codebase is of good quality and maintainable.

Most of the following are not mandatory, but we really encourage and appreciate if follow as much of them as you can.

Commits

We follow the rules enforced by Conventional Commits, meaning that commits should start with the type of the commit followed by an optional scope and then the commit message.

example:

feat(cli): add an extra flag # Good ✅
Add extra feature # Bad ❌

Pull Requests

• PRs’ names’ should also follow the rules of Conventional Commits.
• PRs should be descriptive as possible.
• Breaking changes should be stated clearly in the description.
• All checks must pass before merging unless there is an exception.

Changesets

It is very preferable to add a changeset at the end of your work in the PR.

We use Changesets Bot to check for changeset in PRs.

Generally after making changes you’ll run

bunx changeset add

and fill in the blanks to create a temporary changeset file with metadata about what you’ve changed that will be submitted to the repo along with your changes, Example.

The Changesets Bot will expect each PR to include such a file, and then after the PR is merged it will process and delete the file.

If your changes don’t affect any major component of the repo (such as changes in the website, which we don’t version tag), you may need to create an empty changeset to make the bot happy:

bunx changeset add --empty

Please refer to changesets documentation for more info.