Skip to content

Latest commit

 

History

History
134 lines (78 loc) · 8.94 KB

File metadata and controls

134 lines (78 loc) · 8.94 KB

Contributing to Pretty TypeScript Errors

First off, thanks for taking the time to contribute!

All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions.

And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:

  • Vote on the open issues at microsoft/vscode to allow for new and better features
  • Star the project
  • Share it on social media
  • Mention the project at local meetups and tell your friends/colleagues
  • Check the help wanted label to see if you can help out

Table of contents

I Have a Question

Search in the issues and discussions before you create a new one. If your question is not answered feel free to create a new discussion. If it concerns a bug consider writing a bug report.

Reporting Bugs

Search the open issues before adding your own bug report. If none exists create a new isse by using the Bug Report template.

Try and add enough information to allow others to reproduce the error, if possible provide code samples or a link to a repository. If a bug cannot be reproduced, it will decrease the odds of it being fixed.

If the bug contains visual elements (like the hover feature), also provide a screenshot to help understand what goes wrong.

Requesting Enhancements & Features

Search in the issues and discussions and feel free to add your own comments to existing requests.

If none exists create a new discussion to dicuss the requested feature or enhancement.

3 of the most requested enhancements and features are grouped in tracking issues:

Set up Local Dev Environment

To setup your local environment clone the project and run npm i to install all dependencies like:

git clone https://github.com/yoavbls/pretty-ts-errors.git
cd pretty-ts-errors
npm i

Mono Repo & Turbo

pretty-ts-errors uses a mono-repo setup to manage the different packages under a single git repository. To run parallel tasks in all packages turbo is used.

See the root package.json for the tasks that can be run. Check the package specific package.json to see what tasks can be run for that package.

When developing it is the easiest to run the dev command in the root of the package:

npm run dev

This will run the dev task in parallel for package of the project, thus immediatly propegating changes troughout the repo. For more info on the project architecture, read ARCHITECTURE.md. For more info on debugging and testing see this section.

Issues with Local Dev Setup

If you have issues with setting up your local dev environment, feel free to create a new discussion to ask for help.

Contributing to the Source Code

If you are looking to contribute to the source code check the issues for what to work on. The label good first issue is a good place to start, and consider checking the help wanted to see if you can contribute. You can also tinker with the code, but it is preferred to have an existing issue to link to before you open a PR.

Keep in mind that there is a Stability & Performance impact when running extensions in VS Code, always keep in mind that the extension (code) should contribute to a users workflow, not diminish it.

Architecture

See the ARCHITECTURE.md for more information about the project architecture.

Styleguide

There is no specific styleguide to adhere to, besides the eslint and prettier commands that will lint and format the project. Try to keep the style similar to what already exists to keep the source code easier to read and maintain. Fundamental changes can always be discussed in PR's.

Debugging & Testing

Debugging

See the .vscode/launch.json for the available debug configurations. You can use the VS Code debugger (default F5 key) to start a debugging sessions. It is recommended to use Run Extension (all extensions disabled) to improve startup time when iterating but only loading the default extesions. Use the Run Extension if you want to debug the extension with all your installed extensions enabled.

!NOTE Most Themes and Programming Languages require non-default extensions and will not load when running with Run Extension (all extensions disabled)

When running either of these debug tasks the watch task of the apps/vscode-extension directory will be run in the background, no additional actions are required to debug the extension.

There is a scaffolding setup for automated tests for the VS Code extension, but it is unused yet.

The @pretty-ts-errors/formatter does have some unit tests which uses vitest as a testing framework.

When running the extension with the debugger there is a selectedTextHoverProvider that allows for selecting text in the test directories and treat them as a typescript error message: example of the selected text hover provider

Installing the packaged extension manually

By running the npm run build command, the extension will be build in production mode and packaged as a apps/vscode-extensions/pretty-ts-errors-{version}.vsix file. These files can be installed manually to install the build without having to use the marketplace.

!NOTE When running a manually installed .vsix file, the ExtensionMode will be set to Production.

Testing

To see the currently configured command to run tests, check the .github/workflows/pr-ci.yml.

The packages in packages/ will use test runners to test package specific functionality.

The apps/vscode-extension/ is scaffolded to use the VS Code testing utilities.

Documentation & Resources

The documentation regarding pretty-ts-errors is found in the README.md, CONTRIBUTING.md or the docs directory.

Some comments in the code can be found where specific behaviour or caveats are documented, like the caching mechanism or performance critical sections.

The Visual Studio Code Extension API documentation is a good place to read about the extension API. When external libraries are used, always check and read their respective documentation to ensure they are used properly.

Attribution

This guide is based on the contributing.md. Make your own!