BSL Language Server is an implementation of the Language Server Protocol for 1C (BSL) - the 1C:Enterprise 8 language and OneScript.

This is a Java-based language server that provides code analysis, diagnostics, code actions, and other language features for 1C development.

Key Resources:

• Project site: https://1c-syntax.github.io/bsl-language-server
• Documentation: docs/index.md (Russian), docs/en/index.md (English)
• Contributor's Guide: docs/en/contributing/index.md
• BSL grammar used in BSLParser: https://github.com/1c-syntax/bsl-parser/blob/develop/src/main/antlr/BSLParser.g4
• SDBL grammar used in BSLParser: https://github.com/1c-syntax/bsl-parser/blob/develop/src/main/antlr/SDBLParser.g4

• Language: Java 21
• Build System: Gradle with Kotlin DSL
• Frameworks: Spring Boot
• Key Technologies:
  • ANTLR for parsing
  • Lombok for reducing boilerplate
  • JUnit for testing
  • Language Server Protocol implementation

• Java Development Kit 21
• Gradle (wrapper included in the repository)

./gradlew build

./gradlew test

./gradlew check

When developing new diagnostics or modifying existing ones:

1. Study the Documentation:

   • Review Diagnostic Development Workflow
   • Check Diagnostic Structure
   • Understand Diagnostic Types and Severity

2. Implementation Guidelines:

   • Each diagnostic should have:
     • Java implementation class
     • Resource bundle for localized messages
     • Unit tests
     • Documentation
   • Follow naming conventions from existing diagnostics
   • Use appropriate diagnostic tags and severity levels

3. Testing:

   • Write comprehensive unit tests for each diagnostic
   • Include test cases for edge cases
   • Follow existing test patterns in the codebase

4. Documentation:

   • Update diagnostic documentation in both Russian and English
   • Include examples of problematic code and fixes
   • Document configuration parameters if applicable

1. Code Structure:

   • Main source: src/main/java
   • Tests: src/test/java
   • Resources: src/main/resources, src/test/resources

2. Testing:

   • Always run tests before submitting changes: ./gradlew test
   • Maintain or improve test coverage
   • Use appropriate test frameworks (JUnit, AssertJ, Mockito)

• Follow the Style Guide
• Use Lombok annotations to reduce boilerplate code
• Enable annotation processing in your IDE
• Use EditorConfig for consistent formatting (.editorconfig is provided)

• Optimize imports before committing
• Use automatic import optimization provided by the IDE
• DO NOT optimize imports across the entire project unless specifically working on that task

• Follow Java naming conventions
• Use meaningful, descriptive names
• Keep class and method names concise but clear

• Write JavaDoc for public APIs
• Include comments for complex logic
• Keep documentation up to date with code changes

• build.gradle.kts - Main build configuration
• src/main/java/com/github/_1c_syntax/bsl/languageserver/ - Main source code
  • diagnostics/ - Diagnostic implementations
  • context/ - Language context and parsing
  • providers/ - LSP providers
• src/main/resources/ - Resources, including diagnostic descriptions
• src/test/java/ - Unit tests
• docs/ - Documentation in Russian
• docs/en/ - Documentation in English

The project uses GitHub Actions for CI/CD:

• Quality Assurance: qa.yml - Runs tests and code quality checks
• Pre-QA: pre-qa.yml - Quick validation
• CodeQL: codeql-analysis.yml - Security analysis
• Releases: release.yml - Automated release process

Always ensure your changes pass all CI checks before finalizing.

This project maintains documentation in both Russian and English. When making changes:

• Update documentation in both languages
• Maintain consistency between translations
• Resource bundles should have both Russian and English versions

• Test each diagnostic with multiple scenarios
• Include positive and negative test cases
• Test configuration parameters if applicable
• Use the existing test infrastructure and patterns

• Some diagnostics may require integration testing
• Follow patterns from existing integration tests

# Run all tests
./gradlew test

# Run tests for a specific class
./gradlew test --tests "ClassName"

# Run tests matching a pattern
./gradlew test --tests "*DiagnosticTest"

1. Create diagnostic class in src/main/java/.../diagnostics/
2. Create resource bundles in src/main/resources/.../diagnostics/
3. Add unit tests in src/test/java/.../diagnostics/
4. Add documentation in docs/diagnostics/ and docs/en/diagnostics/
5. Register the diagnostic if needed
6. Run tests and ensure they pass

1. Write a failing test that reproduces the bug
2. Fix the bug with minimal changes
3. Ensure all tests pass
4. Update documentation if the behavior changes

• Dependencies are managed in build.gradle.kts
• Always test thoroughly after dependency updates
• Check for breaking changes in release notes

• Never commit sensitive data or credentials
• Be cautious with external dependencies
• Review security alerts from CodeQL and Dependabot
• Follow secure coding practices

• FAQ
• System Requirements
• Events API
• Performance Measurement
• Diagnostic Tags
• Adding Parameters to Diagnostics
• Adding QuickFixes

• This is a mature, production-quality project with high standards
• Maintain backward compatibility unless explicitly breaking changes are planned
• Follow the existing patterns and conventions strictly
• When in doubt, refer to similar existing code for guidance
• Always run the full test suite before considering a task complete
• Respect the bilingual nature of documentation and resources