Skip to content

Commit

Permalink
feat(babel): remove babel compile
Browse files Browse the repository at this point in the history
BREAKING CHANGE: import paths
  • Loading branch information
Ahmad Nassri committed Mar 18, 2018
1 parent 5409aa0 commit 61a1b97
Show file tree
Hide file tree
Showing 23 changed files with 511 additions and 189 deletions.
28 changes: 0 additions & 28 deletions .babelrc

This file was deleted.

30 changes: 22 additions & 8 deletions .codeclimate.yml
Original file line number Diff line number Diff line change
@@ -1,17 +1,31 @@
engines:
fixme:
enabled: true
version: "2"

plugins:
duplication:
enabled: true
config:
languages:
- javascript
javascript:
patterns:
- test/*.js

eslint:
enabled: true

ratings:
paths:
- src/**
- test/**
fixme:
enabled: true

nodesecurity:
enabled: true

markdownlint:
enabled: true

editorconfig:
enabled: true
channel: beta

exclude_patterns:
- .nyc_output/**
- coverage/**
- node_modules/**
1 change: 0 additions & 1 deletion .editorconfig
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@
# http://editorconfig.org
root = true

[*]
Expand Down
3 changes: 3 additions & 0 deletions .eslintrc
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"extends": "standard"
}
73 changes: 73 additions & 0 deletions .github/CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# Contributor Covenant Code of Conduct

## Our Pledge

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
education, socio-economic status, nationality, personal appearance, race,
religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.

## Scope

This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

[homepage]: https://www.contributor-covenant.org
76 changes: 76 additions & 0 deletions .github/COMMIT_CONVENTION.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
## Commit Message Guidelines

We have very precise rules over how our git commit messages can be formatted. This leads to **more
readable messages** that are easy to follow when looking through the **project history**. But also,
we use the git commit messages to **generate the change log**.


### Commit Message Format

> Before reading any further, We reccomend using [Commitizen](https://github.com/commitizen/cz-cli) to automate creating commit messagess.
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](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.

Samples: _(even more [samples](../../commits/master))_

```
docs(readme): update API example
```
```
refactor(core): rename `bindX()` functions to `interpolationX()`
rationale: remove the confusion with `bind()` and `bind0()`
PR Close #22229
```

### Type
Must be one of the following:

* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing tests or correcting existing tests
* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* **chore**: Other changes that don't modify src or test files
* **revert**: Reverts a previous commit

### Scope
The scope should be the name of the module affected (as perceived by person reading changelog generated from commit messages).

### 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. The rest of the commit message is then used for this.
48 changes: 48 additions & 0 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# Contributing Guide

Before submitting your contribution, please make sure to take a moment and read through the following guidelines.

- [Code of Conduct](#code-of-conduct)
- [Issue Reporting Guidelines](#issue-reporting-guidelines)
- [Pull Request Guidelines](#pull-request-guidelines)
- [Development Setup](#development-setup)
- [Project Structure](#project-structure)

## Code of Conduct

This project is governed by the [Contributor Covenant version 1.4][code-of-conduct]. All contributors and participants agree to abide by its terms. To report violations, send an email to [email protected].

## Issue Reporting Guidelines

Follow the provided [Issue Template](./ISSUE_TEMPLATE.md) to ensure a fast and direct response.

## Pull Request Guidelines

- The `master` branch is basically just a snapshot of the latest stable release. All development should be done in dedicated branches.
- It's OK to have multiple small commits as you work on the PR - we will let GitHub automatically squash it before merging.
- Make sure `npm test` passes **on all supported Node versions**. _(see [development setup](#development-setup))_
- If fixing a bug:
- If you are resolving a special issue, add `(fix #xxxx[,#xxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
- Provide detailed description of the bug in the PR.

## Development Setup

You will need [Node.js](http://nodejs.org), we typically target **ALL [LTS][lts] versions**, confirm this project's list of supported versions in `package.json`

We use Code Climate CLI as a pre-test step to run some validations, you can download and run the [Code Climate CLI](https://github.com/codeclimate/codeclimate) yourself, or rely on the CI Server to run it when you make your PR

### Committing Changes

Commit messages should follow the [commit message convention](./COMMIT_CONVENTION.md) so that changelogs can be automatically generated. Commit messages will be automatically validated upon commit.

### NPM scripts

There are a few scripts available in the `scripts` section of the `package.json` file.

The default `test` script will do the following:

* run `codeclimate analyze` as a pre-test step
* runs `tap test` with enforcement of 100% coverage

[code-of-conduct]: ./CODE_OF_CONDUCT.md
[lts]: https://github.com/nodejs/Release
42 changes: 42 additions & 0 deletions .github/ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
<!-- Provide a general summary of the issue in the Title above -->

### I'm submitting a...
<!-- Check one of the following options with "x" -->

- [ ] Regression (a behavior that used to work and stopped working in a new release)
- [ ] Bug report <!-- Please search GitHub for a similar issue or PR before submitting -->
- [ ] Feature request
- [ ] Documentation issue or request
- [ ] Support request

## Detailed Description
<!-- Provide a detailed description of the issue, change or addition you are proposing -->

### Expected Behavior
<!-- If you're describing a bug, tell us what should happen -->
<!-- If you're suggesting a change/improvement, tell us how it should work -->

### Current Behavior
<!-- If describing a bug, tell us what happens instead of the expected behavior -->
<!-- If suggesting a change/improvement, explain the difference from current behavior -->

### Possible Solution
<!-- Not obligatory, but suggest a fix/reason for the bug, -->
<!-- or ideas how to implement the addition or change -->

## Context
<!-- Why is this change important to you? How would you use it? -->
<!-- How can it benefit other users? -->

### Simplest Example to Reproduce
<!-- If describing a bug, tell us what request options we can use to reproduce the same bug/behavior -->

### Your Environment
<!-- Include as many relevant details about the environment you experienced the bug in -->

| software | version
| ---------------- | -------
| package |
| node |
| npm |
| Operating System |
41 changes: 41 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
<!-- Provide a general summary of your changes in the Title above -->

## Description
<!-- Describe your changes in detail -->

## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->
<!-- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->

## Screenshots (if appropriate):

## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->

- [ ] Bugfix
- [ ] Feature
- [ ] Performance Improvement
- [ ] Tests _(fix, improvement, new tests)_
- [ ] Code style update _(formatting, local variables)_
- [ ] Refactoring _(no functional changes, no api changes)_
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Other... Please describe:

## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have run `npm test` locally and all tests are passing.
- [ ] I have added/updated tests for any new behavior.
- [ ] I have reviewed the [guidelines for contributing](../CONTRIBUTING.md) to this repository.
Loading

0 comments on commit 61a1b97

Please sign in to comment.