205 lines (153 loc) · 8.21 KB

Contributing to NativeScript

👍 First of all, thank you for taking the time to contribute! 👍

Here are some guides on how to do that:

Code of Conduct
Reporting Bugs
Requesting New Features
Submitting a PR
Commit Message Guidelines

Code of Conduct

Help us keep a healthy and open community. We expect all participants in this project to adhere to the NativeScript Code Of Conduct.

Reporting Bugs

Always update to the most recent master release; the bug may already be resolved.
Search for similar issues in the issues list for this repo; it may already be an identified problem.
If this is a bug or problem that is clear, simple, and is unlikely to require any discussion -- it is OK to open an issue on GitHub with a reproduction of the bug including workflows and screenshots. If possible, submit a Pull Request with a failing test, entire application or module. If you'd rather take matters into your own hands, fix the bug yourself (jump down to the Submitting a PR section).

Requesting Features

Use Github Issues to submit feature requests.
First, search for a similar request and extend it if applicable. This way it would be easier for the community to track the features.
When requesting a new feature, please provide as much detail as possible about why you need the feature in your apps. We prefer that you explain a need rather than explain a technical solution for it. That might trigger a nice conversation on finding the best and broadest technical solution to a specific need.

Submitting a PR

Before you begin:

Read and sign the NativeScript Contribution License Agreement.
Make sure there is an issue for the bug or feature you will be working on.

Following these steps is the best way to get you code included in the project:

Fork and clone the NativeScript repo:

git clone https://github.com/<your-git-username>/NativeScript.git
# Navigate to the newly cloned directory
cd NativeScript
# Add an "upstream" remote pointing to the original {N} repo.
git remote add upstream https://github.com/NativeScript/NativeScript.git

Set up the project (for detailed info check our development workflow guide):

#In the repo root
npm install
npm run setup

Create a branch for your PR

git checkout -b <my-fix-branch> master

The fun part! Make your code changes. Make sure you:
- Follow the code conventions guide.
- Write unit tests for your fix or feature. Check out writing unit tests guide.
Before you submit your PR:
- Rebase your changes to the latest master: git pull --rebase upstream master.
- Ensure all unit test are green for Android and iOS. Check running unit tests.
- Ensure your changes pass tslint validation. (run npm run tslint in the root of the repo).
Push your fork. If you have rebased you might have to use force-push your branch:

git push origin <my-fix-branch> --force

Submit your pull request. Please, fill in the Pull Request template - it will help us better understand the PR and increase the chances of it getting merged quickly.

It's our turn from there on! We will review the PR and discuss changes you might have to make before merging it! Thanks!

Commit Message Guidelines

Please follow the git commit message format described below when committing your changes or submitting a PR. That allows us to use the commit messages to generate a change log for every new release.

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

Footer should contain a closing reference to an issue if any.

Samples:

docs(README): add link to NativeScript roadmap

fix(ios-layouts): switch contentInsetAdjustmentBehavior on ScrollView

Do not auto adjust the ScrollView insets, by disabling contentInsetAdjustmentBehavior property, when ScrollView is used as a root Page element.

release: cut the 3.2.0 release

Revert

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Type

Must be one of the following:

build: Changes that affect the build system or external dependencies (example scopes: npm, grunt)
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Jenkins)
docs: Documentation only changes
feat: A new feature
fix: A bug fix
fix-next: A fix for a bug in the master branch, that's not yet released
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
release: Reference commit for the git tag of the release
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
test: Adding missing tests or correcting existing tests (example scopes: e2e, name-of-the-test-app)

Scope

The scope should be the name of the affected component in the code. If the change affects only one of the target platforms (android, ios) that should be specified in the scope.

Sample scopes for the tns-core-modules package:

android/application
ios/application
action-bar
animations
date-picker
profiling

Subject

The subject contains succinct description of the change:

use the imperative, present tense: "change" not "changed" nor "changes"
don't capitalize first letter
no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. Describe the changes and provide a migration guide for any code that may be affected. Sample:

feat: Angular 4.2 support

BREAKING CHANGES:


NativeScriptModule should be imported only in the root application
module (usually named AppModule).
ApplicationModule.
All other NgModules in the app (both feature and lazy-loaded ones)
should import the NativeScriptCommonModule instead.
The behaviour is alligned with BrowserModule and CommonModule in web
Angular apps. angular.io/guide/ngmodule-faq#q-browser-vs-common-module
Migration steps:
In all NgModules, instead of the root one, replace:

import { NativeScriptModule } from "nativescript-angular/nativescript.module";
…
@NgModule({
    imports: [
        NativeScriptModule,
    ]
…
})

with: 

import { NativeScriptCommonModule } from "nativescript-angular/common";
…
@NgModule({
    imports: [
        NativeScriptCommonModule,
    ]
…
})

The above guidelines are based on the AngularJS Git Commit Message Conventions. A detailed explanation and additional examples can be found in this document.

Where to Start

If you want to contribute, but you are not sure where to start - look for issues labeled help wanted.

NativeScript/CONTRIBUTING.md at master · jackyglony/NativeScript · GitHub

Expand file tree

Breadcrumbs

CONTRIBUTING.md

Latest commit

History