diff --git a/wiki/contributing/code-organization.md b/wiki/contributing/code-organization.md index 8ce67ee17dc..a4cf33a38f4 100644 --- a/wiki/contributing/code-organization.md +++ b/wiki/contributing/code-organization.md @@ -16,13 +16,13 @@ The `core` is partitioned into the following layers: The `core` of Code is fully implemented in [TypeScript](https://github.com/microsoft/typescript). Inside each layer the code is organized by the target runtime environment. This ensures that only the runtime specific APIs are used. In the code we distinguish between the following target environments: - `common`: Source code that only requires basic JavaScript APIs and run in all the other target environments - `browser`: Source code that requires the `browser` APIs like access to the DOM - - may use code from: `common` + - may use code from: `common` - `node`: Source code that requires [`nodejs`](https://nodejs.org) APIs - - may use code from: `common` + - may use code from: `common` - `electron-browser`: Source code that requires the [Electron renderer-process](https://github.com/atom/electron/tree/master/docs#modules-for-the-renderer-process-web-page) APIs - - may use code from: `common`, `browser`, `node` + - may use code from: `common`, `browser`, `node` - `electron-main`: Source code that requires the [Electron main-process](https://github.com/atom/electron/tree/master/docs#modules-for-the-main-process) APIs - - may use code from: `common`, `node` + - may use code from: `common`, `node` # Dependency Injection diff --git a/wiki/contributing/coding-guidelines.md b/wiki/contributing/coding-guidelines.md index 1bcac5ffa0d..71a53ab9252 100644 --- a/wiki/contributing/coding-guidelines.md +++ b/wiki/contributing/coding-guidelines.md @@ -4,7 +4,7 @@ We prefer a **rebase workflow** and occasional **feature branches**. Most work happens directly on the `master` branch. For that reason, we recommend setting the `pull.rebase` setting to true. -``` +```bash git config --global pull.rebase true ``` @@ -34,18 +34,18 @@ We use tabs, not spaces. * Use arrow functions `=>` over anonymous function expressions * Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct: -``` javascript - x => x + x - (x,y) => x + y - (x: T, y: T) => x === y +```javascript +x => x + x +(x,y) => x + y +(x: T, y: T) => x === y ``` * Always surround loop and conditional bodies with curly braces * Open curly braces always go on the same line as whatever necessitates them * Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example: -``` javascript - for (var i = 0, n = str.length; i < 10; i++) { } - if (x < 10) { } - function f(x: number, y: string): void { } +```javascript +for (var i = 0, n = str.length; i < 10; i++) { } +if (x < 10) { } +function f(x: number, y: string): void { } ``` \ No newline at end of file diff --git a/wiki/contributing/contributor-license-agreement.md b/wiki/contributing/contributor-license-agreement.md index 29410312fb8..bec0e316b2c 100644 --- a/wiki/contributing/contributor-license-agreement.md +++ b/wiki/contributing/contributor-license-agreement.md @@ -1,4 +1,5 @@ # Contributor License Agreement + You must sign a Contribution License Agreement (CLA) before your PR will be merged. This a one-time requirement for Microsoft projects in GitHub. You can read more about [Contribution License Agreements (CLA)](https://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia. However, you don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. diff --git a/wiki/contributing/how-to-contribute.md b/wiki/contributing/how-to-contribute.md index 785db52fcce..7127d408686 100644 --- a/wiki/contributing/how-to-contribute.md +++ b/wiki/contributing/how-to-contribute.md @@ -18,16 +18,19 @@ Code includes node module dependencies that require native compilation. To ensur For native compilation, you will need [Python](https://www.python.org/downloads/) (version `v2.7` recommended, `v3.x.x` is __*not*__ supported), as well as a C/C++ compiler tool chain. -**Windows:** +**Windows** + * In addition to [Python v2.7](https://www.python.org/downloads/release/python-279/), make sure you have a PYTHON environment variable set to `drive:\path\to\python.exe`, not to a folder * [Visual Studio 2013 for Windows Desktop](https://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx) or [Visual Studio 2015](https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx), make sure to select the option to install all C++ tools and the Windows SDK **OS X** + * Command line developer tools * Python should be installed already * [XCode](https://developer.apple.com/xcode/downloads/) and the Command Line Tools (XCode -> Preferences -> Downloads), which will install `gcc` and the related toolchain containing `make` **Linux** + * Python v2.7 * `make` * A proper C/C++11 compiler tool chain, for example [GCC](https://gcc.gnu.org) @@ -38,23 +41,29 @@ After you have these tools installed, run the following commands to check out Co **OS X** - git clone https://github.com/microsoft/vscode - cd vscode - ./scripts/npm.sh install +```bash +git clone https://github.com/microsoft/vscode +cd vscode +./scripts/npm.sh install +``` **Windows** - git clone https://github.com/microsoft/vscode - cd vscode - scripts\npm install +```bash +git clone https://github.com/microsoft/vscode +cd vscode +scripts\npm install +``` **Linux** - git clone https://github.com/microsoft/vscode - cd vscode - ./scripts/npm.sh install --arch=x64 - # for 32bit Linux - #./scripts/npm.sh install --arch=ia32 +```bash +git clone https://github.com/microsoft/vscode +cd vscode +./scripts/npm.sh install --arch=x64 +# for 32bit Linux +#./scripts/npm.sh install --arch=ia32 +``` **Note:** For more information on how to install NPM modules globally on UNIX systems without resorting to `sudo`, refer to [this guide](http://www.johnpapa.net/how-to-use-npm-global-without-sudo-on-osx/) . @@ -81,13 +90,17 @@ Errors and warnings will show in the console while developing Code. If you use V ### Validate your changes To test the changes you launch a development version of VS Code on the workspace `vscode`, which you are currently editing. -OS X and Linux +**OS X and Linux** - ./scripts/code.sh +```bash +./scripts/code.sh +``` -Windows +**Windows** - .\scripts\code.bat +```bash +.\scripts\code.bat +``` You can identify the development version of Code by the Electron icon in the Dock or Taskbar. @@ -102,12 +115,15 @@ The **render** process runs the UI code inside the Shell window. To debug code r * Install the [Debugger for Chrome](https://marketplace.visualstudio.com/items/msjsdiag.debugger-for-chrome) extension. This extension will let you attach to and debug client side code running in Chrome. * Launch the development version of Code with the following command line option: -OSX and Linux -``` bash +**OS X and Linux** + +```bash ./scripts/code.sh --remote-debugging-port=9222 ``` -Windows -``` bash + +**Windows** + +```bash scripts\code --remote-debugging-port=9222 ``` @@ -115,11 +131,10 @@ scripts\code --remote-debugging-port=9222 #### Using the Chrome Developer Tools - * Run the `Developer: Toggle Developer Tools` command from the Command Palette in your development instance of Code to launch the Chrome tools. * It's also possible to debug the released versions of Code, since the sources link to sourcemaps hosted online. -[![](images/sourcemaps.png)](images/sourcemaps.png) +![](images/sourcemaps.png) The **extension host** process runs code implemented by a plugin. To debug extensions (including those packaged with Code) which run in the extension host process, you can use VS Code itself. Switch to the Debug viewlet, choose the `Attach to Extension Host` configuration, and press F5. @@ -146,5 +161,4 @@ Check out the [issues list](https://github.com/Microsoft/vscode/issues?utf8=%E2% We're also interested in your feedback for the future of Code. You can submit a suggestion or feature request through the issue tracker. To make this process more effective, we're asking that these include more information to help define them more clearly. ## Discussion Etiquette - In order to keep the conversation clear and transparent, please limit discussion to English and keep things on topic with the issue. Be considerate to others and try to be courteous and professional at all times. \ No newline at end of file diff --git a/wiki/project-management/development-process.md b/wiki/project-management/development-process.md index 4b4af163f5f..7f9b10e2092 100644 --- a/wiki/project-management/development-process.md +++ b/wiki/project-management/development-process.md @@ -20,8 +20,8 @@ We work in weekly segments: - **Week 2**: Work according the plan - **Week 3+**: Work according the plan - **Final Week**: End game - - the team tests the new features according a test plan and updates the documentation. - - we make a pre-release available on the 'insiders' channel and invite users to help us test the pre-release. + - the team tests the new features according a test plan and updates the documentation. + - we make a pre-release available on the 'insiders' channel and invite users to help us test the pre-release. ## Triage Bugs and features will be assigned a milestone and within a milestone they will be assigned a priority. The priority dictates the order in which issues should be addressed. A `important` bug (something that we think is critical for the milestone) is to be addressed before the other bugs.