mirror of
https://github.com/coleam00/bolt.new-any-llm
synced 2024-12-28 06:42:56 +00:00
docs: updated Contributing
updated Contributing in the docs updated Contributing and FAQ in the GitHub part as well
This commit is contained in:
Dustin Loring
parent
2638c1a704
commit
7e70dc5d8e
268
CONTRIBUTING.md
268
CONTRIBUTING.md
@ -1,217 +1,219 @@
|
||||
# Contributing to bolt.diy
|
||||
# Contribution Guidelines
|
||||
|
||||
First off, thank you for considering contributing to bolt.diy! This fork aims to expand the capabilities of the original project by integrating multiple LLM providers and enhancing functionality. Every contribution helps make bolt.diy a better tool for developers worldwide.
|
||||
Welcome! This guide provides all the details you need to contribute effectively to the project. Thank you for helping us make **bolt.diy** a better tool for developers worldwide. 💡
|
||||
|
||||
---
|
||||
|
||||
## 📋 Table of Contents
|
||||
- [Code of Conduct](#code-of-conduct)
|
||||
- [How Can I Contribute?](#how-can-i-contribute)
|
||||
- [Pull Request Guidelines](#pull-request-guidelines)
|
||||
- [Coding Standards](#coding-standards)
|
||||
- [Development Setup](#development-setup)
|
||||
- [Deploymnt with Docker](#docker-deployment-documentation)
|
||||
- [Project Structure](#project-structure)
|
||||
|
||||
## Code of Conduct
|
||||
1. [Code of Conduct](#code-of-conduct)
|
||||
2. [How Can I Contribute?](#how-can-i-contribute)
|
||||
3. [Pull Request Guidelines](#pull-request-guidelines)
|
||||
4. [Coding Standards](#coding-standards)
|
||||
5. [Development Setup](#development-setup)
|
||||
6. [Testing](#testing)
|
||||
7. [Deployment](#deployment)
|
||||
8. [Docker Deployment](#docker-deployment)
|
||||
9. [VS Code Dev Containers Integration](#vs-code-dev-containers-integration)
|
||||
|
||||
This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project maintainers.
|
||||
---
|
||||
|
||||
## How Can I Contribute?
|
||||
## 🛡️ Code of Conduct
|
||||
|
||||
### 🐞 Reporting Bugs and Feature Requests
|
||||
- Check the issue tracker to avoid duplicates
|
||||
- Use the issue templates when available
|
||||
- Include as much relevant information as possible
|
||||
- For bugs, add steps to reproduce the issue
|
||||
This project is governed by our **Code of Conduct**. By participating, you agree to uphold this code. Report unacceptable behavior to the project maintainers.
|
||||
|
||||
### 🔧 Code Contributions
|
||||
1. Fork the repository
|
||||
2. Create a new branch for your feature/fix
|
||||
3. Write your code
|
||||
4. Submit a pull request
|
||||
---
|
||||
|
||||
### ✨ Becoming a Core Contributor
|
||||
We're looking for dedicated contributors to help maintain and grow this project. If you're interested in becoming a core contributor, please fill out our [Contributor Application Form](https://forms.gle/TBSteXSDCtBDwr5m7).
|
||||
## 🛠️ How Can I Contribute?
|
||||
|
||||
## Pull Request Guidelines
|
||||
### 1️⃣ Reporting Bugs or Feature Requests
|
||||
- Check the [issue tracker](#) to avoid duplicates.
|
||||
- Use issue templates (if available).
|
||||
- Provide detailed, relevant information and steps to reproduce bugs.
|
||||
|
||||
### 📝 PR Checklist
|
||||
- [ ] Branch from the main branch
|
||||
- [ ] Update documentation if needed
|
||||
- [ ] Manually verify all new functionality works as expected
|
||||
- [ ] Keep PRs focused and atomic
|
||||
### 2️⃣ Code Contributions
|
||||
1. Fork the repository.
|
||||
2. Create a feature or fix branch.
|
||||
3. Write and test your code.
|
||||
4. Submit a pull request (PR).
|
||||
|
||||
### 👀 Review Process
|
||||
1. Manually test the changes
|
||||
2. At least one maintainer review required
|
||||
3. Address all review comments
|
||||
4. Maintain clean commit history
|
||||
### 3️⃣ Join as a Core Contributor
|
||||
Interested in maintaining and growing the project? Fill out our [Contributor Application Form](https://forms.gle/TBSteXSDCtBDwr5m7).
|
||||
|
||||
## Coding Standards
|
||||
---
|
||||
|
||||
### 💻 General Guidelines
|
||||
- Follow existing code style
|
||||
- Comment complex logic
|
||||
- Keep functions focused and small
|
||||
- Use meaningful variable names
|
||||
- Lint your code. This repo contains a pre-commit-hook that will verify your code is linted properly,
|
||||
so set up your IDE to do that for you!
|
||||
## ✅ Pull Request Guidelines
|
||||
|
||||
## Development Setup
|
||||
### PR Checklist
|
||||
- Branch from the **main** branch.
|
||||
- Update documentation, if needed.
|
||||
- Test all functionality manually.
|
||||
- Focus on one feature/bug per PR.
|
||||
|
||||
### 🔄 Initial Setup
|
||||
1. Clone the repository:
|
||||
### Review Process
|
||||
1. Manual testing by reviewers.
|
||||
2. At least one maintainer review required.
|
||||
3. Address review comments.
|
||||
4. Maintain a clean commit history.
|
||||
|
||||
---
|
||||
|
||||
## 📏 Coding Standards
|
||||
|
||||
### General Guidelines
|
||||
- Follow existing code style.
|
||||
- Comment complex logic.
|
||||
- Keep functions small and focused.
|
||||
- Use meaningful variable names.
|
||||
|
||||
---
|
||||
|
||||
## 🖥️ Development Setup
|
||||
|
||||
### 1️⃣ Initial Setup
|
||||
- Clone the repository:
|
||||
```bash
|
||||
git clone https://github.com/coleam00/bolt.new-any-llm.git
|
||||
git clone https://github.com/stackblitz-labs/bolt.diy.git
|
||||
```
|
||||
|
||||
2. Install dependencies:
|
||||
- Install dependencies:
|
||||
```bash
|
||||
pnpm install
|
||||
```
|
||||
|
||||
3. Set up environment variables:
|
||||
- Rename `.env.example` to `.env.local`
|
||||
- Add your LLM API keys (only set the ones you plan to use):
|
||||
- Set up environment variables:
|
||||
1. Rename `.env.example` to `.env.local`.
|
||||
2. Add your API keys:
|
||||
```bash
|
||||
GROQ_API_KEY=XXX
|
||||
HuggingFace_API_KEY=XXX
|
||||
OPENAI_API_KEY=XXX
|
||||
ANTHROPIC_API_KEY=XXX
|
||||
...
|
||||
```
|
||||
- Optionally set debug level:
|
||||
```bash
|
||||
VITE_LOG_LEVEL=debug
|
||||
```
|
||||
3. Optionally set:
|
||||
- Debug level: `VITE_LOG_LEVEL=debug`
|
||||
- Context size: `DEFAULT_NUM_CTX=32768`
|
||||
|
||||
- Optionally set context size:
|
||||
```bash
|
||||
DEFAULT_NUM_CTX=32768
|
||||
```
|
||||
**Note**: Never commit your `.env.local` file to version control. It’s already in `.gitignore`.
|
||||
|
||||
Some Example Context Values for the qwen2.5-coder:32b models are.
|
||||
|
||||
* DEFAULT_NUM_CTX=32768 - Consumes 36GB of VRAM
|
||||
* DEFAULT_NUM_CTX=24576 - Consumes 32GB of VRAM
|
||||
* DEFAULT_NUM_CTX=12288 - Consumes 26GB of VRAM
|
||||
* DEFAULT_NUM_CTX=6144 - Consumes 24GB of VRAM
|
||||
|
||||
**Important**: Never commit your `.env.local` file to version control. It's already included in .gitignore.
|
||||
|
||||
### 🚀 Running the Development Server
|
||||
### 2️⃣ Run Development Server
|
||||
```bash
|
||||
pnpm run dev
|
||||
```
|
||||
**Tip**: Use **Google Chrome Canary** for local testing.
|
||||
|
||||
**Note**: You will need Google Chrome Canary to run this locally if you use Chrome! It's an easy install and a good browser for web development anyway.
|
||||
---
|
||||
|
||||
## Testing
|
||||
## 🧪 Testing
|
||||
|
||||
Run the test suite with:
|
||||
|
||||
```bash
|
||||
pnpm test
|
||||
```
|
||||
|
||||
## Deployment
|
||||
---
|
||||
|
||||
To deploy the application to Cloudflare Pages:
|
||||
## 🚀 Deployment
|
||||
|
||||
### Deploy to Cloudflare Pages
|
||||
```bash
|
||||
pnpm run deploy
|
||||
```
|
||||
Ensure you have required permissions and that Wrangler is configured.
|
||||
|
||||
Make sure you have the necessary permissions and Wrangler is correctly configured for your Cloudflare account.
|
||||
---
|
||||
|
||||
# Docker Deployment Documentation
|
||||
## 🐳 Docker Deployment
|
||||
|
||||
This guide outlines various methods for building and deploying the application using Docker.
|
||||
This section outlines the methods for deploying the application using Docker. The processes for **Development** and **Production** are provided separately for clarity.
|
||||
|
||||
## Build Methods
|
||||
---
|
||||
|
||||
### 1. Using Helper Scripts
|
||||
### 🧑💻 Development Environment
|
||||
|
||||
NPM scripts are provided for convenient building:
|
||||
#### Build Options
|
||||
|
||||
**Option 1: Helper Scripts**
|
||||
```bash
|
||||
# Development build
|
||||
npm run dockerbuild
|
||||
```
|
||||
|
||||
**Option 2: Direct Docker Build Command**
|
||||
```bash
|
||||
docker build . --target bolt-ai-development
|
||||
```
|
||||
|
||||
**Option 3: Docker Compose Profile**
|
||||
```bash
|
||||
docker-compose --profile development up
|
||||
```
|
||||
|
||||
#### Running the Development Container
|
||||
```bash
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:development
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🏭 Production Environment
|
||||
|
||||
#### Build Options
|
||||
|
||||
**Option 1: Helper Scripts**
|
||||
```bash
|
||||
# Production build
|
||||
npm run dockerbuild:prod
|
||||
```
|
||||
|
||||
### 2. Direct Docker Build Commands
|
||||
|
||||
You can use Docker's target feature to specify the build environment:
|
||||
|
||||
**Option 2: Direct Docker Build Command**
|
||||
```bash
|
||||
# Development build
|
||||
docker build . --target bolt-ai-development
|
||||
|
||||
# Production build
|
||||
docker build . --target bolt-ai-production
|
||||
```
|
||||
|
||||
### 3. Docker Compose with Profiles
|
||||
|
||||
Use Docker Compose profiles to manage different environments:
|
||||
|
||||
**Option 3: Docker Compose Profile**
|
||||
```bash
|
||||
# Development environment
|
||||
docker-compose --profile development up
|
||||
|
||||
# Production environment
|
||||
docker-compose --profile production up
|
||||
```
|
||||
|
||||
## Running the Application
|
||||
|
||||
After building using any of the methods above, run the container with:
|
||||
|
||||
#### Running the Production Container
|
||||
```bash
|
||||
# Development
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:development
|
||||
|
||||
# Production
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:production
|
||||
```
|
||||
|
||||
## Deployment with Coolify
|
||||
---
|
||||
|
||||
[Coolify](https://github.com/coollabsio/coolify) provides a straightforward deployment process:
|
||||
### Coolify Deployment
|
||||
|
||||
1. Import your Git repository as a new project
|
||||
2. Select your target environment (development/production)
|
||||
3. Choose "Docker Compose" as the Build Pack
|
||||
4. Configure deployment domains
|
||||
5. Set the custom start command:
|
||||
For an easy deployment process, use [Coolify](https://github.com/coollabsio/coolify):
|
||||
1. Import your Git repository into Coolify.
|
||||
2. Choose **Docker Compose** as the build pack.
|
||||
3. Configure environment variables (e.g., API keys).
|
||||
4. Set the start command:
|
||||
```bash
|
||||
docker compose --profile production up
|
||||
```
|
||||
6. Configure environment variables
|
||||
- Add necessary AI API keys
|
||||
- Adjust other environment variables as needed
|
||||
7. Deploy the application
|
||||
|
||||
## VS Code Integration
|
||||
---
|
||||
|
||||
The `docker-compose.yaml` configuration is compatible with VS Code dev containers:
|
||||
## 🛠️ VS Code Dev Containers Integration
|
||||
|
||||
1. Open the command palette in VS Code
|
||||
2. Select the dev container configuration
|
||||
3. Choose the "development" profile from the context menu
|
||||
The `docker-compose.yaml` configuration is compatible with **VS Code Dev Containers**, making it easy to set up a development environment directly in Visual Studio Code.
|
||||
|
||||
## Environment Files
|
||||
### Steps to Use Dev Containers
|
||||
|
||||
Ensure you have the appropriate `.env.local` file configured before running the containers. This file should contain:
|
||||
- API keys
|
||||
- Environment-specific configurations
|
||||
- Other required environment variables
|
||||
1. Open the command palette in VS Code (`Ctrl+Shift+P` or `Cmd+Shift+P` on macOS).
|
||||
2. Select **Dev Containers: Reopen in Container**.
|
||||
3. Choose the **development** profile when prompted.
|
||||
4. VS Code will rebuild the container and open it with the pre-configured environment.
|
||||
|
||||
## Notes
|
||||
---
|
||||
|
||||
- Port 5173 is exposed and mapped for both development and production environments
|
||||
- Environment variables are loaded from `.env.local`
|
||||
- Different profiles (development/production) can be used for different deployment scenarios
|
||||
- The configuration supports both local development and production deployment
|
||||
## 🔑 Environment Variables
|
||||
|
||||
Ensure `.env.local` is configured correctly with:
|
||||
- API keys.
|
||||
- Context-specific configurations.
|
||||
|
||||
Example for the `DEFAULT_NUM_CTX` variable:
|
||||
```bash
|
||||
DEFAULT_NUM_CTX=24576 # Uses 32GB VRAM
|
||||
```
|
||||
84
FAQ.md
84
FAQ.md
@ -1,8 +1,7 @@
|
||||
[](https://bolt.diy)
|
||||
# Frequently Asked Questions (FAQ)
|
||||
|
||||
# bolt.diy
|
||||
|
||||
## Recommended Models for bolt.diy
|
||||
<details>
|
||||
<summary><strong>What are the best models for bolt.diy?</strong></summary>
|
||||
|
||||
For the best experience with bolt.diy, we recommend using the following models:
|
||||
|
||||
@ -13,51 +12,80 @@ For the best experience with bolt.diy, we recommend using the following models:
|
||||
- **Qwen 2.5 Coder 32b**: Best model for self-hosting with reasonable hardware requirements
|
||||
|
||||
**Note**: Models with less than 7b parameters typically lack the capability to properly interact with bolt!
|
||||
</details>
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><strong>How do I get the best results with bolt.diy?</strong></summary>
|
||||
|
||||
### How do I get the best results with bolt.diy?
|
||||
- **Be specific about your stack**:
|
||||
Mention the frameworks or libraries you want to use (e.g., Astro, Tailwind, ShadCN) in your initial prompt. This ensures that bolt.diy scaffolds the project according to your preferences.
|
||||
|
||||
- **Be specific about your stack**: If you want to use specific frameworks or libraries (like Astro, Tailwind, ShadCN, or any other popular JavaScript framework), mention them in your initial prompt to ensure bolt scaffolds the project accordingly.
|
||||
- **Use the enhance prompt icon**:
|
||||
Before sending your prompt, click the *enhance* icon to let the AI refine your prompt. You can edit the suggested improvements before submitting.
|
||||
|
||||
- **Use the enhance prompt icon**: Before sending your prompt, try clicking the 'enhance' icon to have the AI model help you refine your prompt, then edit the results before submitting.
|
||||
- **Scaffold the basics first, then add features**:
|
||||
Ensure the foundational structure of your application is in place before introducing advanced functionality. This helps bolt.diy establish a solid base to build on.
|
||||
|
||||
- **Scaffold the basics first, then add features**: Make sure the basic structure of your application is in place before diving into more advanced functionality. This helps Bolt.diy understand the foundation of your project and ensure everything is wired up right before building out more advanced functionality.
|
||||
- **Batch simple instructions**:
|
||||
Combine simple tasks into a single prompt to save time and reduce API credit consumption. For example:
|
||||
*"Change the color scheme, add mobile responsiveness, and restart the dev server."*
|
||||
</details>
|
||||
|
||||
- **Batch simple instructions**: Save time by combining simple instructions into one message. For example, you can ask Bolt.diy to change the color scheme, add mobile responsiveness, and restart the dev server, all in one go saving you time and reducing API credit consumption significantly.
|
||||
<details>
|
||||
<summary><strong>How do I contribute to bolt.diy?</strong></summary>
|
||||
|
||||
### Why are there so many open issues/pull requests?
|
||||
Check out our [Contribution Guide](CONTRIBUTING.md) for more details on how to get involved!
|
||||
</details>
|
||||
|
||||
bolt.diy was started simply to showcase how to edit an open source project and to do something cool with local LLMs on my (@ColeMedin) YouTube channel! However, it quickly grew into a massive community project that I am working hard to keep up with the demand of by forming a team of maintainers and getting as many people involved as I can. That effort is going well and all of our maintainers are ABSOLUTE rockstars, but it still takes time to organize everything so we can efficiently get through all the issues and PRs. But rest assured, we are working hard and even working on some partnerships behind the scenes to really help this project take off!
|
||||
<details>
|
||||
<summary><strong>What are the future plans for bolt.diy?</strong></summary>
|
||||
|
||||
### How do local LLMs fair compared to larger models like Claude 3.5 Sonnet for bolt.diy/bolt.new?
|
||||
Visit our [Roadmap](https://roadmap.sh/r/ottodev-roadmap-2ovzo) for the latest updates.
|
||||
New features and improvements are on the way!
|
||||
</details>
|
||||
|
||||
As much as the gap is quickly closing between open source and massive close source models, you’re still going to get the best results with the very large models like GPT-4o, Claude 3.5 Sonnet, and DeepSeek Coder V2 236b. This is one of the big tasks we have at hand - figuring out how to prompt better, use agents, and improve the platform as a whole to make it work better for even the smaller local LLMs!
|
||||
<details>
|
||||
<summary><strong>Why are there so many open issues/pull requests?</strong></summary>
|
||||
|
||||
### I'm getting the error: "There was an error processing this request"
|
||||
bolt.diy began as a small showcase project on @ColeMedin's YouTube channel to explore editing open-source projects with local LLMs. However, it quickly grew into a massive community effort!
|
||||
|
||||
If you see this error within bolt.diy, that is just the application telling you there is a problem at a high level, and this could mean a number of different things. To find the actual error, please check BOTH the terminal where you started the application (with Docker or pnpm) and the developer console in the browser. For most browsers, you can access the developer console by pressing F12 or right clicking anywhere in the browser and selecting “Inspect”. Then go to the “console” tab in the top right.
|
||||
We're forming a team of maintainers to manage demand and streamline issue resolution. The maintainers are rockstars, and we're also exploring partnerships to help the project thrive.
|
||||
</details>
|
||||
|
||||
### I'm getting the error: "x-api-key header missing"
|
||||
<details>
|
||||
<summary><strong>How do local LLMs compare to larger models like Claude 3.5 Sonnet for bolt.diy?</strong></summary>
|
||||
|
||||
We have seen this error a couple times and for some reason just restarting the Docker container has fixed it. This seems to be Ollama specific. Another thing to try is try to run bolt.diy with Docker or pnpm, whichever you didn’t run first. We are still on the hunt for why this happens once and a while!
|
||||
While local LLMs are improving rapidly, larger models like GPT-4o, Claude 3.5 Sonnet, and DeepSeek Coder V2 236b still offer the best results for complex applications. Our ongoing focus is to improve prompts, agents, and the platform to better support smaller local LLMs.
|
||||
</details>
|
||||
|
||||
### I'm getting a blank preview when bolt.diy runs my app!
|
||||
<details>
|
||||
<summary><strong>Common Errors and Troubleshooting</strong></summary>
|
||||
|
||||
We promise you that we are constantly testing new PRs coming into bolt.diy and the preview is core functionality, so the application is not broken! When you get a blank preview or don’t get a preview, this is generally because the LLM hallucinated bad code or incorrect commands. We are working on making this more transparent so it is obvious. Sometimes the error will appear in developer console too so check that as well.
|
||||
### **"There was an error processing this request"**
|
||||
This generic error message means something went wrong. Check both:
|
||||
- The terminal (if you started the app with Docker or `pnpm`).
|
||||
- The developer console in your browser (press `F12` or right-click > *Inspect*, then go to the *Console* tab).
|
||||
|
||||
### Everything works but the results are bad
|
||||
### **"x-api-key header missing"**
|
||||
This error is sometimes resolved by restarting the Docker container.
|
||||
If that doesn't work, try switching from Docker to `pnpm` or vice versa. We're actively investigating this issue.
|
||||
|
||||
This goes to the point above about how local LLMs are getting very powerful but you still are going to see better (sometimes much better) results with the largest LLMs like GPT-4o, Claude 3.5 Sonnet, and DeepSeek Coder V2 236b. If you are using smaller LLMs like Qwen-2.5-Coder, consider it more experimental and educational at this point. It can build smaller applications really well, which is super impressive for a local LLM, but for larger scale applications you want to use the larger LLMs still!
|
||||
### **Blank preview when running the app**
|
||||
A blank preview often occurs due to hallucinated bad code or incorrect commands.
|
||||
To troubleshoot:
|
||||
- Check the developer console for errors.
|
||||
- Remember, previews are core functionality, so the app isn't broken! We're working on making these errors more transparent.
|
||||
|
||||
### Received structured exception #0xc0000005: access violation
|
||||
### **"Everything works, but the results are bad"**
|
||||
Local LLMs like Qwen-2.5-Coder are powerful for small applications but still experimental for larger projects. For better results, consider using larger models like GPT-4o, Claude 3.5 Sonnet, or DeepSeek Coder V2 236b.
|
||||
|
||||
### **"Received structured exception #0xc0000005: access violation"**
|
||||
If you are getting this, you are probably on Windows. The fix is generally to update the [Visual C++ Redistributable](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170)
|
||||
|
||||
### How to add an LLM:
|
||||
### **"Miniflare or Wrangler errors in Windows"**
|
||||
You will need to make sure you have the latest version of Visual Studio C++ installed (14.40.33816), more information here https://github.com/stackblitz-labs/bolt.diy/issues/19.
|
||||
</details>
|
||||
|
||||
To make new LLMs available to use in this version of bolt.new, head on over to `app/utils/constants.ts` and find the constant MODEL_LIST. Each element in this array is an object that has the model ID for the name (get this from the provider's API documentation), a label for the frontend model dropdown, and the provider.
|
||||
---
|
||||
|
||||
By default, many providers are already implemented, but the YouTube video for this repo covers how to extend this to work with more providers if you wish!
|
||||
|
||||
When you add a new model to the MODEL_LIST array, it will immediately be available to use when you run the app locally or reload it.
|
||||
Got more questions? Feel free to reach out or open an issue in our GitHub repo!
|
||||
|
||||
@ -1,246 +1,219 @@
|
||||
# Contribution Guidelines
|
||||
|
||||
Welcome! This guide provides all the details you need to contribute effectively to the project. Thank you for helping us make **bolt.diy** a better tool for developers worldwide. 💡
|
||||
|
||||
---
|
||||
|
||||
## 📋 Table of Contents
|
||||
- [Code of Conduct](#code-of-conduct)
|
||||
- [How Can I Contribute?](#how-can-i-contribute)
|
||||
- [Pull Request Guidelines](#pull-request-guidelines)
|
||||
- [Coding Standards](#coding-standards)
|
||||
- [Development Setup](#development-setup)
|
||||
- [Deploymnt with Docker](#docker-deployment-documentation)
|
||||
|
||||
1. [Code of Conduct](#code-of-conduct)
|
||||
2. [How Can I Contribute?](#how-can-i-contribute)
|
||||
3. [Pull Request Guidelines](#pull-request-guidelines)
|
||||
4. [Coding Standards](#coding-standards)
|
||||
5. [Development Setup](#development-setup)
|
||||
6. [Testing](#testing)
|
||||
7. [Deployment](#deployment)
|
||||
8. [Docker Deployment](#docker-deployment)
|
||||
9. [VS Code Dev Containers Integration](#vs-code-dev-containers-integration)
|
||||
|
||||
---
|
||||
|
||||
## Code of Conduct
|
||||
## 🛡️ Code of Conduct
|
||||
|
||||
This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project maintainers.
|
||||
This project is governed by our **Code of Conduct**. By participating, you agree to uphold this code. Report unacceptable behavior to the project maintainers.
|
||||
|
||||
---
|
||||
|
||||
## How Can I Contribute?
|
||||
## 🛠️ How Can I Contribute?
|
||||
|
||||
### 🐞 Reporting Bugs and Feature Requests
|
||||
- Check the issue tracker to avoid duplicates
|
||||
- Use the issue templates when available
|
||||
- Include as much relevant information as possible
|
||||
- For bugs, add steps to reproduce the issue
|
||||
### 1️⃣ Reporting Bugs or Feature Requests
|
||||
- Check the [issue tracker](#) to avoid duplicates.
|
||||
- Use issue templates (if available).
|
||||
- Provide detailed, relevant information and steps to reproduce bugs.
|
||||
|
||||
### 🔧 Code Contributions
|
||||
1. Fork the repository
|
||||
2. Create a new branch for your feature/fix
|
||||
3. Write your code
|
||||
4. Submit a pull request
|
||||
### 2️⃣ Code Contributions
|
||||
1. Fork the repository.
|
||||
2. Create a feature or fix branch.
|
||||
3. Write and test your code.
|
||||
4. Submit a pull request (PR).
|
||||
|
||||
### ✨ Becoming a Core Contributor
|
||||
We're looking for dedicated contributors to help maintain and grow this project. If you're interested in becoming a core contributor, please fill out our [Contributor Application Form](https://forms.gle/TBSteXSDCtBDwr5m7).
|
||||
### 3️⃣ Join as a Core Contributor
|
||||
Interested in maintaining and growing the project? Fill out our [Contributor Application Form](https://forms.gle/TBSteXSDCtBDwr5m7).
|
||||
|
||||
---
|
||||
|
||||
## Pull Request Guidelines
|
||||
## ✅ Pull Request Guidelines
|
||||
|
||||
### 📝 PR Checklist
|
||||
- [ ] Branch from the main branch
|
||||
- [ ] Update documentation if needed
|
||||
- [ ] Manually verify all new functionality works as expected
|
||||
- [ ] Keep PRs focused and atomic
|
||||
### PR Checklist
|
||||
- Branch from the **main** branch.
|
||||
- Update documentation, if needed.
|
||||
- Test all functionality manually.
|
||||
- Focus on one feature/bug per PR.
|
||||
|
||||
### 👀 Review Process
|
||||
1. Manually test the changes
|
||||
2. At least one maintainer review required
|
||||
3. Address all review comments
|
||||
4. Maintain clean commit history
|
||||
### Review Process
|
||||
1. Manual testing by reviewers.
|
||||
2. At least one maintainer review required.
|
||||
3. Address review comments.
|
||||
4. Maintain a clean commit history.
|
||||
|
||||
---
|
||||
|
||||
## Coding Standards
|
||||
## 📏 Coding Standards
|
||||
|
||||
### 💻 General Guidelines
|
||||
- Follow existing code style
|
||||
- Comment complex logic
|
||||
- Keep functions focused and small
|
||||
- Use meaningful variable names
|
||||
### General Guidelines
|
||||
- Follow existing code style.
|
||||
- Comment complex logic.
|
||||
- Keep functions small and focused.
|
||||
- Use meaningful variable names.
|
||||
|
||||
---
|
||||
|
||||
## Development Setup
|
||||
## 🖥️ Development Setup
|
||||
|
||||
### 🔄 Initial Setup
|
||||
1. Clone the repository:
|
||||
### 1️⃣ Initial Setup
|
||||
- Clone the repository:
|
||||
```bash
|
||||
git clone https://github.com/stackblitz-labs/bolt.diy.git
|
||||
```
|
||||
|
||||
2. Install dependencies:
|
||||
- Install dependencies:
|
||||
```bash
|
||||
pnpm install
|
||||
```
|
||||
|
||||
3. Set up environment variables:
|
||||
- Rename `.env.example` to `.env.local`
|
||||
- Add your LLM API keys (only set the ones you plan to use):
|
||||
- Set up environment variables:
|
||||
1. Rename `.env.example` to `.env.local`.
|
||||
2. Add your API keys:
|
||||
```bash
|
||||
GROQ_API_KEY=XXX
|
||||
HuggingFace_API_KEY=XXX
|
||||
OPENAI_API_KEY=XXX
|
||||
ANTHROPIC_API_KEY=XXX
|
||||
...
|
||||
```
|
||||
- Optionally set debug level:
|
||||
```bash
|
||||
VITE_LOG_LEVEL=debug
|
||||
```
|
||||
3. Optionally set:
|
||||
- Debug level: `VITE_LOG_LEVEL=debug`
|
||||
- Context size: `DEFAULT_NUM_CTX=32768`
|
||||
|
||||
- Optionally set context size:
|
||||
```bash
|
||||
DEFAULT_NUM_CTX=32768
|
||||
```
|
||||
**Note**: Never commit your `.env.local` file to version control. It’s already in `.gitignore`.
|
||||
|
||||
Some Example Context Values for the qwen2.5-coder:32b models are.
|
||||
|
||||
* DEFAULT_NUM_CTX=32768 - Consumes 36GB of VRAM
|
||||
* DEFAULT_NUM_CTX=24576 - Consumes 32GB of VRAM
|
||||
* DEFAULT_NUM_CTX=12288 - Consumes 26GB of VRAM
|
||||
* DEFAULT_NUM_CTX=6144 - Consumes 24GB of VRAM
|
||||
|
||||
**Important**: Never commit your `.env.local` file to version control. It's already included in .gitignore.
|
||||
|
||||
### 🚀 Running the Development Server
|
||||
### 2️⃣ Run Development Server
|
||||
```bash
|
||||
pnpm run dev
|
||||
```
|
||||
|
||||
**Note**: You will need Google Chrome Canary to run this locally if you use Chrome! It's an easy install and a good browser for web development anyway.
|
||||
**Tip**: Use **Google Chrome Canary** for local testing.
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
## 🧪 Testing
|
||||
|
||||
Run the test suite with:
|
||||
|
||||
```bash
|
||||
pnpm test
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Deployment
|
||||
|
||||
To deploy the application to Cloudflare Pages:
|
||||
## 🚀 Deployment
|
||||
|
||||
### Deploy to Cloudflare Pages
|
||||
```bash
|
||||
pnpm run deploy
|
||||
```
|
||||
|
||||
Make sure you have the necessary permissions and Wrangler is correctly configured for your Cloudflare account.
|
||||
Ensure you have required permissions and that Wrangler is configured.
|
||||
|
||||
---
|
||||
|
||||
# Docker Deployment Documentation
|
||||
## 🐳 Docker Deployment
|
||||
|
||||
This guide outlines various methods for building and deploying the application using Docker.
|
||||
This section outlines the methods for deploying the application using Docker. The processes for **Development** and **Production** are provided separately for clarity.
|
||||
|
||||
## Build Methods
|
||||
---
|
||||
|
||||
### 1. Using Helper Scripts
|
||||
### 🧑💻 Development Environment
|
||||
|
||||
NPM scripts are provided for convenient building:
|
||||
#### Build Options
|
||||
|
||||
**Option 1: Helper Scripts**
|
||||
```bash
|
||||
# Development build
|
||||
npm run dockerbuild
|
||||
```
|
||||
|
||||
**Option 2: Direct Docker Build Command**
|
||||
```bash
|
||||
docker build . --target bolt-ai-development
|
||||
```
|
||||
|
||||
**Option 3: Docker Compose Profile**
|
||||
```bash
|
||||
docker-compose --profile development up
|
||||
```
|
||||
|
||||
#### Running the Development Container
|
||||
```bash
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:development
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🏭 Production Environment
|
||||
|
||||
#### Build Options
|
||||
|
||||
**Option 1: Helper Scripts**
|
||||
```bash
|
||||
# Production build
|
||||
npm run dockerbuild:prod
|
||||
```
|
||||
|
||||
### 2. Direct Docker Build Commands
|
||||
|
||||
You can use Docker's target feature to specify the build environment:
|
||||
|
||||
**Option 2: Direct Docker Build Command**
|
||||
```bash
|
||||
# Development build
|
||||
docker build . --target bolt-ai-development
|
||||
|
||||
# Production build
|
||||
docker build . --target bolt-ai-production
|
||||
```
|
||||
|
||||
### 3. Docker Compose with Profiles
|
||||
|
||||
Use Docker Compose profiles to manage different environments:
|
||||
|
||||
**Option 3: Docker Compose Profile**
|
||||
```bash
|
||||
# Development environment
|
||||
docker-compose --profile development up
|
||||
|
||||
# Production environment
|
||||
docker-compose --profile production up
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Running the Application
|
||||
|
||||
After building using any of the methods above, run the container with:
|
||||
|
||||
#### Running the Production Container
|
||||
```bash
|
||||
# Development
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:development
|
||||
|
||||
# Production
|
||||
docker run -p 5173:5173 --env-file .env.local bolt-ai:production
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Deployment with Coolify
|
||||
### Coolify Deployment
|
||||
|
||||
[Coolify](https://github.com/coollabsio/coolify) provides a straightforward deployment process:
|
||||
|
||||
1. Import your Git repository as a new project
|
||||
2. Select your target environment (development/production)
|
||||
3. Choose "Docker Compose" as the Build Pack
|
||||
4. Configure deployment domains
|
||||
5. Set the custom start command:
|
||||
For an easy deployment process, use [Coolify](https://github.com/coollabsio/coolify):
|
||||
1. Import your Git repository into Coolify.
|
||||
2. Choose **Docker Compose** as the build pack.
|
||||
3. Configure environment variables (e.g., API keys).
|
||||
4. Set the start command:
|
||||
```bash
|
||||
docker compose --profile production up
|
||||
```
|
||||
6. Configure environment variables
|
||||
- Add necessary AI API keys
|
||||
- Adjust other environment variables as needed
|
||||
7. Deploy the application
|
||||
|
||||
---
|
||||
|
||||
## VS Code Integration
|
||||
## 🛠️ VS Code Dev Containers Integration
|
||||
|
||||
The `docker-compose.yaml` configuration is compatible with VS Code dev containers:
|
||||
The `docker-compose.yaml` configuration is compatible with **VS Code Dev Containers**, making it easy to set up a development environment directly in Visual Studio Code.
|
||||
|
||||
1. Open the command palette in VS Code
|
||||
2. Select the dev container configuration
|
||||
3. Choose the "development" profile from the context menu
|
||||
### Steps to Use Dev Containers
|
||||
|
||||
1. Open the command palette in VS Code (`Ctrl+Shift+P` or `Cmd+Shift+P` on macOS).
|
||||
2. Select **Dev Containers: Reopen in Container**.
|
||||
3. Choose the **development** profile when prompted.
|
||||
4. VS Code will rebuild the container and open it with the pre-configured environment.
|
||||
|
||||
---
|
||||
|
||||
## Environment Files
|
||||
## 🔑 Environment Variables
|
||||
|
||||
Ensure you have the appropriate `.env.local` file configured before running the containers. This file should contain:
|
||||
- API keys
|
||||
- Environment-specific configurations
|
||||
- Other required environment variables
|
||||
Ensure `.env.local` is configured correctly with:
|
||||
- API keys.
|
||||
- Context-specific configurations.
|
||||
|
||||
---
|
||||
|
||||
## DEFAULT_NUM_CTX
|
||||
|
||||
The `DEFAULT_NUM_CTX` environment variable can be used to limit the maximum number of context values used by the qwen2.5-coder model. For example, to limit the context to 24576 values (which uses 32GB of VRAM), set `DEFAULT_NUM_CTX=24576` in your `.env.local` file.
|
||||
|
||||
First off, thank you for considering contributing to bolt.diy! This fork aims to expand the capabilities of the original project by integrating multiple LLM providers and enhancing functionality. Every contribution helps make bolt.diy a better tool for developers worldwide.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- Port 5173 is exposed and mapped for both development and production environments
|
||||
- Environment variables are loaded from `.env.local`
|
||||
- Different profiles (development/production) can be used for different deployment scenarios
|
||||
- The configuration supports both local development and production deployment
|
||||
Example for the `DEFAULT_NUM_CTX` variable:
|
||||
```bash
|
||||
DEFAULT_NUM_CTX=24576 # Uses 32GB VRAM
|
||||
```
|
||||
Loading…
Reference in New Issue
Block a user