Please check out the
before creating a new issue
Before doing any meaningful work or even investigating please create an issue for discussion so we don't have duplicate work and we don't step on your toes.
Hacking on atom-typescript
Consequently, please avoid editing files in
dist/ directly, since
those are generated and your changes will be gone after the next build.
Also see the Atom contributing guide
Is rather simple. Here are some steps to get you running:
Fork the repository (the button in top right corner of GitHub page)
Clone your fork
- With SSH:
git clone email@example.com:yourusername/atom-typescript.git
- With HTTPS:
git clone https://github.com/yourusername/atom-typescript.git
Either of these commands will create a working copy of the repository in
All further commands in this list are assumed to be run from root of the working copy (i.e.
atom-typescriptdirectory, the one containing
- With SSH:
Create a new branch!
git checkout -b my-awesome-contribution. Please use a meaningful name for your branch.
Install dependencies with
Install development dependencies with
npm install --only=dev.
apm linkif you want to test your changes in Atom. Be careful if you're using
atom-typescriptto hack on
atom-typescriptthough! You'd be hacking on the software using the same software you're currently hacking on, which sounds somewhat convoluted because it is. See section on workflow below for some tips.
Hack on it!
Prettify the code by running
npm run prettier
npm run build
Run static checks with
npm run test(this will run typechecker and linter, and check if formatting is OK)
Run dynamic test-suite with
apm test(at the moment, it's rather anemic and only checks if package loads at all)
Commit your changes. Don't forget to commit transpiled source in
dist/. Write a meaningful description for your commit! Push often! Repeat steps 4-9 until satisfied.
Create a pull request.
Note: feel free to create pull requests at any stage of the process. Earlier is usually better. For one, creating PRs early is a good way of letting people know you're working on something, which helps avoid effort duplication. Also it will allow maintainers to chime in early and help you avoid pitfalls and common mistakes.
Whenever you pull in latest changes, you should run
Whenever we update to latest TypeScript we need to recompile all our js
to make sure everybody gets the same code.
You need to have git. Note on windows long file paths can be an issue so run:
git config --system core.longpaths true
Shift+Delete to delete files if simple
delete doesn't work.
- If you have only fixed bugs in a backward-compatible way (or
consider your changes very minimal), run
apm publish patch.
- If you have implemented new functionality, run
apm publish minor. (A TypeScript update should at least be minor).
- For breaking changes run
apm publish major. These must be justified with a reason documented in
apmcommand does a lot for you that you shouldn't do manually. It automatically updates the
creates a git tag+
pushes to git+
pushes to apm.
- On windows : storing your github password using
git config --global credential.helper wincredhelps smooth out the
apm publish <type>experience.
We develop atom-typescript with atom-typescript
ctrl+shift+i(View → Developer → Toggle Developer Tools... menu item) will open the dev tools. These are the same Chrome dev tools you may be familiar with. Feel free to inspect elements. This will come handy when doing UI or even seeing why a particular code element is highlighted in some way.
window:reloadcommand) will reload the entire atom instance.
- We open
atom-typescriptsource in one Atom window
- We have
atom-typescript-examplesopen in another atom window as such:
atom --dev <examplesFolder>
- We make changes to
atom-typescriptand save to get the JS (optionally run
typescript:buildcommand to rebuild everything)
- We typecheck whole project with
typescript:check-all-filescommand to see if our changes accidentally broke anything.
- We reload the
ctrl+shift+f5) window to see the effects of our change.
- Only reload the
atom-typescriptwindow once we are sure that our new code is functional.
When you break atom-typescript during development
This shouldn't happen as long as you start the
--dev flag, and do testing in another atom instance. If
you reload the
atom-typescript window thinking its going to be stable
think broke it and reload the atom instance.
For example, this will revert to last commit:
git checkout dist
And if you need to go back to
git checkout origin/master -- dist
Language Service Documentation
The TypeScript Language service docs: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
tsserver protocol definitions
Showing errors in atom
Done using Linter V2 Indie API.