If you wish to contribute to the extension, please read this guide to understand the processes and standards we use.
If you want to register an issue, use Formatter bug template.
- Fork this repository.
- Visit the Issues tab, and find an issue or bug you'd like to work on.
- Create a new branch for your bug fix or new feature.
- Commit your changes and push them to your branch on GitHub.
- Submit a pull request (PR) to the main repository.
The following sections provide more detailed technical information and standard practices used in this project.
The current .wasm file is included in the resources folder.
If your changes require reinstalling the extension, follow these steps:
- In the terminal, run:
npm run package. - A .vsix file should be generated.
- Install the extension from this file.
If you need to fix a parser bug or modify the tree-sitter parser:
- Make sure Python is installed on your computer.
- Tree-sitter-abl (https://github.com/eglekaz/tree-sitter-abl) is the parser that we use for the formatter, so clone it.
- In the parser directory, run:
node-gyp configure. - Install emcc (https://github.com/emscripten-core/emsdk.git), add it to your
PATH, and verify the installation.
For more details, see the tree-sitter documentation or the tree-sitter-abl repository.
After making changes to the parser:
- Run
npm run test(only continue if the tests pass). - Run
npm run build:wasm(this will build the .wasm file in the tree-sitter repo). - Move the new .wasm file to the
resourcesfolder in your formatter branch. - Refer to the instructions in the Using the Existing .wasm File for the Extension section to finish installation.
Note:
For contributions to the tree-sitter-abl repository, follow the standard GitHub fork-and-PR workflow:
- Create a new branch in tree-sitter-abl.
- Commit your changes and push them.
- Submit a pull request.
When contributing, please follow these conventions:
- Variable and folder names are written in English and use Camel Case (Multiple words are joined together without spaces or underscores, and each word's first letter is capitalized except for the first word).
- File names can be written in Camel and Pascal Case.
- For functional test file names, use the test order number and a short description (e.g., 4assign-array-literal). If multiple tests are needed for a specific case, append a unique number (e.g., 4assign-array-literal3).
- If you are implementing a new feature, write functional tests that cover both typical usage and relevant edge cases. Ensure your tests follow the standard ABL coding conventions (https://conf.baltic-amadeus.lt/pages/viewpage.action?pageId=20423083).
- Ensure all tests (functionality, symbol, AST) pass in your GitHub PR pipeline.
- In classes, methods should be indented by four spaces.
All test suites are automatically run when you create a pull request (PR). To run the tests locally in Visual Studio Code:
- Click on the Run and Debug icon in the left sidebar (or press Ctrl+Shift+D).
- In the dropdown menu, select the test suite you want to run.
- Click the green Start button (▶) or press F5 to start the test chosen tests.
- See whether the tests pass or not live in the Debug console.
- For information on debugging and formatter configuration, see the README.md in this repository.
- Formatters for ABL syntax structures are in
src/formatters. Files for node tree iteration and formatter application are insrc/formatterFramework. - If any tests fail, you can view the detailed results in the
resources/testResultsdirectory.
