Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions .cursorrules
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# filesql

filesql is a library that implements the common functionality of the following commands: "Load files such as CSV into SQLite3 and execute SQL queries against CSV, etc."
- [sqly](https://github.com/nao1215/sqly): easily execute SQL against CSV/TSV/LTSV/JSON and Microsoft Excel™ with shell.
- [sqluv](https://github.com/nao1215/sqluv): simple terminal UI for RDBMS & CSV/TSV/LTSV at local/https/s3

filesql reads the contents of specified input files and returns [sql.DB](https://pkg.go.dev/database/sql#DB). Developers can execute SQL queries in the same way as the standard sql.DB they normally use, making it easy to learn.

## Codebase Information
### Development Commands
- `make test`: Run tests and measure coverage (generates cover.out file, viewable in browser with cover.html)
- `make lint`: Code inspection with golangci-lint (.golangci.yml configuration)
- `make clean`: Delete generated files
- `make tools`: Install dependency tools (golangci-lint, octocov)

### Key Features
- Input file formats: CSV, TSV, LTSV, Parquet, Excel + compressed versions (.gz, .bz2, .xz, .zst)
- Input methods: File path, directory, io.Reader, embed.FS
- Streaming: Chunk-based processing for large files
- Type inference: Automatic column data type detection (INTEGER/REAL/TEXT)
- Auto-save: Automatic saving at Commit or db.Close timing

## Development Rules
- Test-Driven Development: We adopt the test-driven development promoted by t-wada (Takuto Wada). Always write test code and be mindful of the test pyramid.
- Working code: Ensure that `make test` and `make lint` succeed after completing work.
- Sponsor acquisition: Since development incurs financial costs, we seek sponsors via `https://github.com/sponsors/nao1215`. Include sponsor links in README and documentation.
- Contributor acquisition: Create developer documentation so anyone can participate in development and recruit contributors.
- Comments in English: Write code comments in English to accept international contributors.
- User-friendly documentation comments: Write detailed explanations and example code for public functions so users can understand usage at a glance.

## Coding Guidelines
- No global variables: Do not use global variables. Manage state through function arguments and return values.
- Coding rules: Follow Golang coding rules. [Effective Go](https://go.dev/doc/effective_go) is the basic rule.
- Package comments are mandatory: Describe the package overview in `doc.go` for each package. Clarify the purpose and usage of the package.
- Comments for public functions, variables, and struct fields are mandatory: When visibility is public, always write comments following go doc rules.
- Remove duplicate code: After completing your work, check if you have created duplicate code and remove unnecessary code.
- Update README: When adding new features, update the README at the following paths:
- README.md
- doc/es/README.md
- doc/fr/README.md
- doc/ja/README.md
- doc/ko/README.md
- doc/ru/README.md
- doc/zh-cn/README.md

## Testing
- [Readable Test Code](https://logmi.jp/main/technology/327449): Avoid excessive optimization (DRY) and aim for a state where it's easy to understand what tests exist.
- Clear input/output: Create tests with `t.Run()` and clarify test case input/output. Test cases clarify test intent by explicitly showing input and expected output.
- Test granularity: Aim for 80% or higher coverage with unit tests.
- Parallel test execution: Use `t.Parallel()` to run tests in parallel whenever possible.
- Using `octocov`: Run `octocov` after `make test` to confirm test coverage exceeds 80%.
- Cross-platform support: Tests run on Linux, macOS, and Windows through GitHub Actions. Examples of non-cross-platform code include "concatenating paths without using `filepath.Join`" and "using "\n" for line breaks".
- Test data storage: Store sample files in various formats in the testdata directory

## Important Notes for Cursor
When using Cursor's AI features, please ensure all generated code adheres to these guidelines. Always review and understand the generated code before committing. The AI should help you follow TDD practices by suggesting tests first, then implementation.
61 changes: 61 additions & 0 deletions .github/copilot-instructions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# filesql

filesql is a library that implements the common functionality of the following commands: "Load files such as CSV into SQLite3 and execute SQL queries against CSV, etc."
- [sqly](https://github.com/nao1215/sqly): easily execute SQL against CSV/TSV/LTSV/JSON and Microsoft Excel™ with shell.
- [sqluv](https://github.com/nao1215/sqluv): simple terminal UI for RDBMS & CSV/TSV/LTSV at local/https/s3

filesql reads the contents of specified input files and returns [sql.DB](https://pkg.go.dev/database/sql#DB). Developers can execute SQL queries in the same way as the standard sql.DB they normally use, making it easy to learn.

## Codebase Information
### Development Commands
- `make test`: Run tests and measure coverage (generates cover.out file, viewable in browser with cover.html)
- `make lint`: Code inspection with golangci-lint (.golangci.yml configuration)
- `make clean`: Delete generated files
- `make tools`: Install dependency tools (golangci-lint, octocov)

### Key Features
- Input file formats: CSV, TSV, LTSV, Parquet, Excel + compressed versions (.gz, .bz2, .xz, .zst)
- Input methods: File path, directory, io.Reader, embed.FS
- Streaming: Chunk-based processing for large files
- Type inference: Automatic column data type detection (INTEGER/REAL/TEXT)
- Auto-save: Automatic saving at Commit or db.Close timing

## Development Rules
- Test-Driven Development: We adopt the test-driven development promoted by t-wada (Takuto Wada). Always write test code and be mindful of the test pyramid.
- Working code: Ensure that `make test` and `make lint` succeed after completing work.
- Sponsor acquisition: Since development incurs financial costs, we seek sponsors via `https://github.com/sponsors/nao1215`. Include sponsor links in README and documentation.
- Contributor acquisition: Create developer documentation so anyone can participate in development and recruit contributors.
- Comments in English: Write code comments in English to accept international contributors.
- User-friendly documentation comments: Write detailed explanations and example code for public functions so users can understand usage at a glance.

## Coding Guidelines
- No global variables: Do not use global variables. Manage state through function arguments and return values.
- Coding rules: Follow Golang coding rules. [Effective Go](https://go.dev/doc/effective_go) is the basic rule.
- Package comments are mandatory: Describe the package overview in `doc.go` for each package. Clarify the purpose and usage of the package.
- Comments for public functions, variables, and struct fields are mandatory: When visibility is public, always write comments following go doc rules.
- Remove duplicate code: After completing your work, check if you have created duplicate code and remove unnecessary code.
- Update README: When adding new features, update the README at the following paths:
- README.md
- doc/es/README.md
- doc/fr/README.md
- doc/ja/README.md
- doc/ko/README.md
- doc/ru/README.md
- doc/zh-cn/README.md

## Testing
- [Readable Test Code](https://logmi.jp/main/technology/327449): Avoid excessive optimization (DRY) and aim for a state where it's easy to understand what tests exist.
- Clear input/output: Create tests with `t.Run()` and clarify test case input/output. Test cases clarify test intent by explicitly showing input and expected output.
- Test granularity: Aim for 80% or higher coverage with unit tests.
- Parallel test execution: Use `t.Parallel()` to run tests in parallel whenever possible.
- Using `octocov`: Run `octocov` after `make test` to confirm test coverage exceeds 80%.
- Cross-platform support: Tests run on Linux, macOS, and Windows through GitHub Actions. Examples of non-cross-platform code include "concatenating paths without using `filepath.Join`" and "using "\n" for line breaks".
- Test data storage: Store sample files in various formats in the testdata directory

## GitHub Copilot Instructions
When generating code suggestions, GitHub Copilot should:
1. Always suggest tests before implementation following TDD principles
2. Ensure all generated code follows the Effective Go guidelines
3. Include proper godoc comments for all public APIs
4. Suggest parallel test execution with `t.Parallel()` where appropriate
5. Use `filepath.Join()` for path operations to ensure cross-platform compatibility
53 changes: 53 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# filesql

filesql is a library that implements the common functionality of the following commands: "Load files such as CSV into SQLite3 and execute SQL queries against CSV, etc."
- [sqly](https://github.com/nao1215/sqly): easily execute SQL against CSV/TSV/LTSV/JSON and Microsoft Excel™ with shell.
- [sqluv](https://github.com/nao1215/sqluv): simple terminal UI for RDBMS & CSV/TSV/LTSV at local/https/s3

filesql reads the contents of specified input files and returns [sql.DB](https://pkg.go.dev/database/sql#DB). Developers can execute SQL queries in the same way as the standard sql.DB they normally use, making it easy to learn.

## Codebase Information
### Development Commands
- `make test`: Run tests and measure coverage (generates cover.out file, viewable in browser with cover.html)
- `make lint`: Code inspection with golangci-lint (.golangci.yml configuration)
- `make clean`: Delete generated files
- `make tools`: Install dependency tools (golangci-lint, octocov)

### Key Features
- Input file formats: CSV, TSV, LTSV, Parquet, Excel + compressed versions (.gz, .bz2, .xz, .zst)
- Input methods: File path, directory, io.Reader, embed.FS
- Streaming: Chunk-based processing for large files
- Type inference: Automatic column data type detection (INTEGER/REAL/TEXT)
- Auto-save: Automatic saving at Commit or db.Close timing

## Development Rules
- Test-Driven Development: We adopt the test-driven development promoted by t-wada (Takuto Wada). Always write test code and be mindful of the test pyramid.
- Working code: Ensure that `make test` and `make lint` succeed after completing work.
- Sponsor acquisition: Since development incurs financial costs, we seek sponsors via `https://github.com/sponsors/nao1215`. Include sponsor links in README and documentation.
- Contributor acquisition: Create developer documentation so anyone can participate in development and recruit contributors.
- Comments in English: Write code comments in English to accept international contributors.
- User-friendly documentation comments: Write detailed explanations and example code for public functions so users can understand usage at a glance.

## Coding Guidelines
- No global variables: Do not use global variables. Manage state through function arguments and return values.
- Coding rules: Follow Golang coding rules. [Effective Go](https://go.dev/doc/effective_go) is the basic rule.
- Package comments are mandatory: Describe the package overview in `doc.go` for each package. Clarify the purpose and usage of the package.
- Comments for public functions, variables, and struct fields are mandatory: When visibility is public, always write comments following go doc rules.
- Remove duplicate code: After completing your work, check if you have created duplicate code and remove unnecessary code.
- Update README: When adding new features, update the README at the following paths:
- README.md
- doc/es/README.md
- doc/fr/README.md
- doc/ja/README.md
- doc/ko/README.md
- doc/ru/README.md
- doc/zh-cn/README.md

## Testing
- [Readable Test Code](https://logmi.jp/main/technology/327449): Avoid excessive optimization (DRY) and aim for a state where it's easy to understand what tests exist.
- Clear input/output: Create tests with `t.Run()` and clarify test case input/output. Test cases clarify test intent by explicitly showing input and expected output.
- Test granularity: Aim for 80% or higher coverage with unit tests.
- Parallel test execution: Use `t.Parallel()` to run tests in parallel whenever possible.
- Using `octocov`: Run `octocov` after `make test` to confirm test coverage exceeds 80%.
- Cross-platform support: Tests run on Linux, macOS, and Windows through GitHub Actions. Examples of non-cross-platform code include "concatenating paths without using `filepath.Join`" and "using "\n" for line breaks".
- Test data storage: Store sample files in various formats in the testdata directory
20 changes: 20 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,25 @@ func TestFile_Parse(t *testing.T) {
}
```

## Using AI Assistants (LLMs)

We actively encourage the use of AI coding assistants to improve productivity and code quality. Tools like Claude Code, GitHub Copilot, and Cursor are welcome for:

- Writing boilerplate code
- Generating comprehensive test cases
- Improving documentation
- Refactoring existing code
- Finding potential bugs
- Suggesting performance optimizations
- Translating documentation

### Guidelines for AI-Assisted Development

1. **Review all generated code**: Always review and understand AI-generated code before committing
2. **Maintain consistency**: Ensure AI-generated code follows our coding standards in CLAUDE.md
3. **Test thoroughly**: AI-generated code must pass all tests and linting (`make test` and `make lint`)
4. **Use project configuration**: We provide `CLAUDE.md`, `.cursorrules` and `.github/copilot-instructions.md` to help AI assistants understand our project standards

## Creating Pull Requests

### Preparation
Expand All @@ -120,6 +139,7 @@ func TestFile_Parse(t *testing.T) {
2. **Write Tests**
- Always add tests for new features
- For bug fixes, create tests that reproduce the bug
- AI tools can help generate comprehensive test cases

3. **Quality Check**
```bash
Expand Down
5 changes: 0 additions & 5 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,6 @@ GOOS = ""
GOARCH = ""
GO_PKGROOT = ./...
GO_PACKAGES = $(shell $(GO_LIST) $(GO_PKGROOT))
GO_LDFLAGS = -ldflags '-X github.com/nao1215/sqluv/config.Version=${VERSION}'


clean: ## Clean project
-rm -rf $(APP) cover.*
Expand All @@ -26,9 +24,6 @@ test: ## Start test
env GOOS=$(GOOS) $(GO_TEST) -cover $(GO_PKGROOT) -coverpkg=./... -coverprofile=cover.out
$(GO_TOOL) cover -html=cover.out -o cover.html

gen: ## Generate code from templates
$(GO) generate ./...

tools: ## Install dependency tools
$(GO_INSTALL) github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest
$(GO_INSTALL) github.com/k1LoW/octocov@latest
Expand Down
20 changes: 20 additions & 0 deletions doc/es/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,25 @@ func TestFile_Parse(t *testing.T) {
}
```

## Uso de Asistentes de IA (LLMs)

Fomentamos activamente el uso de asistentes de codificación con IA para mejorar la productividad y la calidad del código. Herramientas como Claude Code, GitHub Copilot y Cursor son bienvenidas para:

- Escribir código repetitivo
- Generar casos de prueba completos
- Mejorar la documentación
- Refactorizar código existente
- Encontrar posibles errores
- Sugerir optimizaciones de rendimiento
- Traducir documentación

### Pautas para el Desarrollo Asistido por IA

1. **Revisar todo el código generado**: Siempre revisa y comprende el código generado por IA antes de hacer commit
2. **Mantener la coherencia**: Asegúrate de que el código generado por IA siga nuestros estándares de codificación en CLAUDE.md
3. **Probar exhaustivamente**: El código generado por IA debe pasar todas las pruebas y el linting (`make test` y `make lint`)
4. **Usar configuración del proyecto**: Proporcionamos `CLAUDE.md`, `.cursorrules` y `.github/copilot-instructions.md` para ayudar a los asistentes de IA a entender nuestros estándares del proyecto

## Crear Pull Requests

### Preparación
Expand All @@ -120,6 +139,7 @@ func TestFile_Parse(t *testing.T) {
2. **Escribir Pruebas**
- Siempre agrega pruebas para nuevas características
- Para correcciones de errores, crea pruebas que reproduzcan el error
- Las herramientas de IA pueden ayudar a generar casos de prueba completos

3. **Verificación de Calidad**
```bash
Expand Down
20 changes: 20 additions & 0 deletions doc/fr/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,25 @@ func TestFile_Parse(t *testing.T) {
}
```

## Utilisation des Assistants IA (LLMs)

Nous encourageons activement l'utilisation d'assistants de codage IA pour améliorer la productivité et la qualité du code. Des outils comme Claude Code, GitHub Copilot et Cursor sont les bienvenus pour :

- Écrire du code répétitif
- Générer des cas de test complets
- Améliorer la documentation
- Refactoriser le code existant
- Trouver des bogues potentiels
- Suggérer des optimisations de performance
- Traduire la documentation

### Directives pour le Développement Assisté par IA

1. **Réviser tout le code généré** : Toujours réviser et comprendre le code généré par l'IA avant de faire un commit
2. **Maintenir la cohérence** : S'assurer que le code généré par l'IA suit nos standards de codage dans CLAUDE.md
3. **Tester minutieusement** : Le code généré par l'IA doit passer tous les tests et le linting (`make test` et `make lint`)
4. **Utiliser la configuration du projet** : Nous fournissons `CLAUDE.md`, `.cursorrules` et `.github/copilot-instructions.md` pour aider les assistants IA à comprendre nos standards de projet

## Créer des Pull Requests

### Préparation
Expand All @@ -120,6 +139,7 @@ func TestFile_Parse(t *testing.T) {
2. **Écrire des Tests**
- Toujours ajouter des tests pour les nouvelles fonctionnalités
- Pour les corrections de bogues, créez des tests qui reproduisent le bogue
- Les outils IA peuvent aider à générer des cas de test complets

3. **Contrôle de Qualité**
```bash
Expand Down
20 changes: 20 additions & 0 deletions doc/ja/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,25 @@ func TestFile_Parse(t *testing.T) {
}
```

## AIアシスタント(LLM)の活用

私たちは生産性と品質向上のため、AIコーディングアシスタントの利用を積極的に推奨しています。Claude Code、GitHub Copilot、Cursorなどのツールは以下の用途で活用できます:

- ボイラープレートコードの生成
- 包括的なテストケースの生成
- ドキュメントの改善
- 既存コードのリファクタリング
- 潜在的なバグの発見
- パフォーマンス最適化の提案
- ドキュメントの翻訳

### AI支援開発のガイドライン

1. **生成コードのレビュー**: AI生成コードは必ずレビューし、理解してからコミットしてください
2. **一貫性の維持**: AI生成コードがCLAUDE.mdのコーディング標準に従っていることを確認してください
3. **徹底的なテスト**: AI生成コードは全てのテストとリンティング(`make test`と`make lint`)に合格する必要があります
4. **プロジェクト設定の利用**: `CLAUDE.md`、`.cursorrules`と`.github/copilot-instructions.md`を用意しており、AIアシスタントがプロジェクト標準を理解できるようになっています

## Pull Requestの作成

### 事前準備
Expand All @@ -120,6 +139,7 @@ func TestFile_Parse(t *testing.T) {
2. **テストの作成**
- 新機能にはテストを必ず追加してください
- バグ修正の場合は、バグを再現するテストを作成してください
- AIツールを使って包括的なテストケースを生成できます

3. **品質チェック**
```bash
Expand Down
Loading
Loading