Skip to content

Commit

Permalink
Merge pull request #12 from EasyAsABC123/FixFeature-PR
Browse files Browse the repository at this point in the history
Updates options to have all Standard Options
  • Loading branch information
pdehaan authored Mar 1, 2017
2 parents 977d75c + a0dcbb3 commit 29c5343
Show file tree
Hide file tree
Showing 11 changed files with 1,982 additions and 114 deletions.
4 changes: 2 additions & 2 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
node_modules
npm-debug.log
tmp
*.log
.DS_Store
1 change: 1 addition & 0 deletions .yarnclean
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@

126 changes: 126 additions & 0 deletions CONTRIBUTE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
# Contribute

Contributions are greatly welcomed! I originally forked this and tweaked things to better serve my needs, and I have no doubt you have improvements too!

When contributing, remember to _**be excellent to one another!**_ If in doubt, please refer to the Code of Conduct below, taken from [@todogroup/opencodeofconduct](https://github.com/todogroup/opencodeofconduct).

## Code of Conduct

### Section 1: Purpose

#### TL;DR

Having a Code of Conduct is our way to encourage good behavior and discourage bad behavior in our open source community.

--------------------------------------------------------------------------------

This Code of Conduct outlines our expectations for participants of this project as well as steps to reporting unacceptable behavior. Our goal is to make explicit what we expect from participants in the open-source community as well as its leaders.

- We explicitly forbid harassment and abusive speech within this community.
- We request that incidents of misconduct be reported to this project's maintainers.
- We urge participants to refrain from using the community discussion forums to play out a fight.

Harassment, verbal abuse, and fighting harms the open-source community. This Code of Conduct articulates a set of behaviors that support a healthier approach to conflict and interaction.

### Section 2: Statement about Diversity

#### TL;DR

We encourage participation from a large group of people who bring different perspectives to the project.

--------------------------------------------------------------------------------

Open-source projects thrive on diverse perspectives. If one smart developer could code the whole project, we'd just hire that developer to write all the code. In reality, complex projects require a diverse perspectives; which you only get when you invite dissimilar people to participate in the group. When you bring people from different backgrounds together on complex projects tensions arise, sometimes leading to verbal abuse and even threats of violence. Establishing a Code of Conduct is one way to signify this project values the perspectives of many. We are committed to ensuring participants have an effective method of escalating reports of misconduct so that we can maintain a productive community for all participants.

### Section 3: Expected Behaviors

#### TL;DR

We expect participants to communicate professionally and thoughtfully. We call out common situations where this is especially important. For example: when people disagree, when people join a project midstream, when people are unclear in their communication style, and when you feel the need to leave the community.

--------------------------------------------------------------------------------

We expect participants in this community to conduct themselves professionally. Since our primary mode of communication is text on an online forum (e.g. issue, pull request, comment, email, or chat text) devoid of vocal tone, gestures, or other context that is often vital to understanding, it is especially important that you convey these attitudes in text. This includes the following behaviors:

- **Assume positive intent.** When someone posts something we expect community members will assume positive intent on the part of the post. We may choose to disagree with the idea and reject the suggestion, but we expect that it was made in order to be supportive of the community goals.
- **Be respectful to participants.** We expect participants will disagree on aspects of this project. Disagreements must remain professional. Even if we reject someone's idea, we continue to welcome their participation. And if your idea is rejected, be more persuasive not bitter.
- **Seek to understand.** Open Source projects can be learning experiences. When someone poses something you find disagreeable or you don't understand it, inquire about it. Ask, explore, challenge, and then assert if you agree or disagree.
- **Be welcoming to new members.** New members bring fresh perspectives. Many will raised questions that have been addressed before, You can point them to existing discussions for them to get up to speed. Don't punish them for being new to the project -- everyone is new to every project once.
- **Be kind to beginners.** Beginners use open source projects to get experience. They might not be talented coders yet, and projects should not accept poor quality code. But we were all beginners once, and we need to to reject code with kindness.
- **Consider your impact on others.** Your work will be used by others, and you depend on the work of others. We expect community members to be considerate and establish a balance their self-interest with communal interest.
- **Use words carefully.** We may not understand intent when you say something ironic. Poe's Law suggests that without an emoticon is it likely that someone will misinterpret sarcasm. We ask community members to communicate plainly.
- **Exit with class.** There may come a time where you stop believing in the project direction or get frustrated with the project leaders. You are always free to fork the code and create a competitive project. Open Source explicitly accommodates this. It does not have to be dramatic or bitter. Sometimes you just walk away, and it's OK.

### Section 4: Unacceptable Behaviors

#### TL;DR

We call out examples of behaviors which cause members to lose their good standing in the community. These include insulting people on the basis of their protected-class status, threatening words, or unwanted sexual attention. Rather than fighting back, please report every incident directly to the project maintainers.

--------------------------------------------------------------------------------

Participants in this open source community remain in good standing when they do not conduct themselves in a manner that violates this Code of Conduct. Misconduct includes:

- Calling out project members by their identity or background in a deliberately negative or insulting manner. This includes but is not limited to slurs or insinuations related to protected or suspect classes such as race, color, citizenship, national origin, political belief, religion, sexual orientation, gender identity and expression, age, size, culture, ethnicity, genetic features, language, profession, membership of a national minority, mental or physical ability.
- Insulting remarks about a person's lifestyle practices.
- Threats of violence or intimidation or any project member.
- Unwanted sexual attention or behavior unsuitable for the topic of the open source project.
- Sustained disruption of discussion.

We cannot list all forms of harassment in an exhaustive manner, nor do we seek to declare some forms of harassment as benign or not worthy of action. Rather, if a project member feels harassed we ask they report the incident. The incident will be recorded and addressed. Furthermore, we insist that the victim of this harassment not address the issue in the forum in public, as this tends to intensify the problem for the parties in question and for the community as a whole.

### Section 5: Reporting Issues

#### TL;DR

Please follow the reporting process so that the maintainers can take action on your report. The maintainers will handle your issue with discretion. We respect your confidentiality for the purpose of protecting victims of abuse.

--------------------------------------------------------------------------------

If you experience or witness misconduct, or have any other concerns about the conduct of members of this project, please report it by contacting us via email. All reports will be handled with discretion.

We ask that your report include:

- Your preferred contact information so we can reach out to you in case of questions. We cannot process anonymous reports.
- Names (real or username) of those involved in the incident.
- Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger), please provide the link so that we can review it.
- Any additional information that may be helpful.

After filing a report, a representative will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. If the person who is harassing you is part of the maintainers, they will recuse themselves from handling your incident. If the complaint originates from a member of the maintainers, it will be handled by a different member of the maintainers. We respect the confidentiality of all requests for the purpose of protecting victims of abuse.

### Section 6: Consequences & Scope

#### TL;DR

This project will assign a respondent role responsible to accept and address misconduct issues. The respondent will apply measured response to remove harassers and harassment from this project. This code does not replace the ToS or AUP of the websites used to support this project. We acknowledge that many participants are also subject to terms of employment which may govern their online expressions.

--------------------------------------------------------------------------------

Each project that implements this code of conduct agrees to assign the role of maintainers to at least one member of the project who has admin rights on the project and legal rights on the project copyright. The maintainers is empowered restrict access or privileges to the project if needed. Since this project is governed by an open source license, any participant may fork the code at any time under the terms of the project license.

The mission of the maintainers is to maintain the productive collaboration that takes place on this open source community. Its goal is to preserve the project if possible, and will restrict or remove participation from members who disrupt the project. The maintainers is tasked with using its judgement to meet its mission, and this is highly dependent upon their understanding of the situation and their wisdom. Should they succeed, this project will be more resilient, and successfully meet its goals.

This code does not replace the terms of service or acceptable use policies that may apply to the websites used to support this community. Nor does this code apply to communications or actions that take place outside of the context of this community. Many of the participants in this project are subject to codes of conduct that apply to them based on their terms of employment. This code is a simple social-contract that informs participants of our social expectations.

### Section 7: Attribution & Acknowledgements

#### TL;DR

We thank those who created codes of conduct and diversity statements that served as our inspiration. Whereas we created our own text, we were very inspired by what we learned reviewing existing work. We publish our version with the invitation to use, modify, and adapt this text to your needs.

--------------------------------------------------------------------------------

We created this code based on input from many existing codes as well as input from many people. We expect that others will use what we created to inspire their efforts too. We call our the following codes as having the most significant impact to our process.

- [Django](https://www.djangoproject.com/conduct/reporting/)
- [Python](https://www.python.org/community/diversity/)
- [Ubuntu](http://www.ubuntu.com/about/about-ubuntu/conduct)
- [Contributor Covenant](http://contributor-covenant.org/)
- [Geek Feminism](http://geekfeminism.org/about/code-of-conduct/)
- [Citizen Code of Conduct](http://citizencodeofconduct.org/)

We acknowledge the hard work put into creating these codes, and point you to them for consideration. We chose to create our own text to suit the needs we felt are applicable to our communities. You are welcome to take our text and use it, copy it, customize it as you see fit for your community. Kindly give us credit for inspiring what you create.

You are invited to suggest edits, or to edit your own version to suit your needs. We believe codes of conduct improve over time, and like good software, evolve to handle new situations and conditions. Whereas there are already many such codes for various projects, we add our voice to the mix and hope this helps improve the social dynamics that take place in our communities. We are confident you will let us know if you disagree, and we ask that you provide that feedback in accord with the expected behaviors listed above.

> _This text is shared under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) license._
5 changes: 0 additions & 5 deletions Gruntfile.js
Original file line number Diff line number Diff line change
Expand Up @@ -9,15 +9,10 @@
'use strict'

module.exports = function (grunt) {
grunt.loadNpmTasks('grunt-nsp-shrinkwrap')

// Project configuration.
grunt.initConfig({
// Configuration to be run (and then tested).
standard: {
options: {
format: false
},
app: {
src: [
'{,lib/,tasks/}*.js'
Expand Down
9 changes: 8 additions & 1 deletion LICENSE
Original file line number Diff line number Diff line change
@@ -1 +1,8 @@
Don't be a dick.
The MIT License (MIT)
Copyright (c) 2017 Justin Schuhmann

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
117 changes: 68 additions & 49 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,61 +1,42 @@
# grunt-standard
# grunt-standard [![JavaScript Standard Style](https://img.shields.io/badge/code%20style-standard-brightgreen.svg)](http://standardjs.com/) [![GitHub release](https://img.shields.io/github/release/EasyAsABC123/grunt-standard.svg)](https://github.com/EasyAsABC123/grunt-standard/releases) [![npm (scoped)](https://img.shields.io/npm/v/grunt-standard.svg)](https://www.npmjs.com/package/grunt-standard) [![license](https://img.shields.io/badge/license-MIT-blue.svg)](https://github.com/EasyAsABC123/grunt-standard/blob/master/LICENSE) [![GitHub issues](https://img.shields.io/github/issues/EasyAsABC123/grunt-standard.svg)](https://github.com/EasyAsABC123/grunt-standard/issues) [![GitHub followers](https://img.shields.io/github/followers/EasyAsABC123.svg?style=social&label=Follow)](https://github.com/EasyAsABC123)

> Grunt plugin for [standard](https://github.com/feross/standard) linter.
> Grunt Plugin for [JavaScript Standard Style](https://github.com/feross/standard) Linting and Formatting
## Getting Started
This plugin requires Grunt `~0.4.5`
> Dependencies up-to-date!
If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
## Install

The following shell commands will install `grunt-standard` to your project's `package.json` in `devDependencies`.

### npm
```shell
npm install grunt-standard --save-dev
```

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

```js
grunt.loadNpmTasks('grunt-standard');
### Yarn
```shell
yarn add grunt-standard --dev
```

## The "standard" task
### Assumptions

### Overview
In your project's Gruntfile, add a section named `standard` to the data object passed into `grunt.initConfig()`.
- You have the latest version of `grunt` in your project's `package.json`'s `devDependencies`.
- You have added the npm task to your project's `Gruntfile.js`.
- You are running the latest version of `node`.

```js
grunt.initConfig({
standard: {
options: {
// Task-specific options go here.
},
your_target: {
// Target-specific file lists and/or options go here.
},
},
});
```javascript
grunt.loadNpmTasks('grunt-standard')
```

### Options

#### options.format
Type: `Boolean`
Default value: `false`

Whether or not the source files should be auto-formatted using [standard-format](https://github.com/maxogden/standard-format).

#### options.lint
Type: `Boolean`
Default value: `true`
## Configure

Whether ot not the source files should be linted using [standard](https://github.com/feross/standard).
In your project's `Gruntfile.js`, add a section named `standard` to the data object passed into `grunt.initConfig()`.

### Usage Examples
### Default

#### Default Options
In this example, the default options are used to lint the specified `*.js` files in the root, `lib/`, and `tasks/` directories:

In this example, the default options are used to lint the specified *.js files in the root directory, lib/ directory, and tasks/ directory:

```js
```javascript
grunt.initConfig({
standard: {
app: {
Expand All @@ -67,15 +48,57 @@ grunt.initConfig({
})
```

#### Custom Options
### Custom

#### options.ignore

- **Type:** `Array`
- **Default:** `[]`
- **Action:** Lint source files using [JavaScript Standard Style](https://github.com/feross/standard#standardlintfilesfiles-opts-callback).

In this example, the `format` option is set to `true` so the source files will be auto-formatted (and written back to disk) before being linted:
#### options.cwd

```js
- **Type:** `String`
- **Default:** `''`
- **Action:** current working directory (default: process.cwd()) [Documentation](https://github.com/feross/standard#standardlintfilesfiles-opts-callback).

#### options.fix

- **Type:** `Boolean`
- **Default:** `false`
- **Action:** Auto-format source files using [standard --fix](https://github.com/feross/standard#is-there-an-automatic-formatter).

#### options.globals

- **Type:** `Array`
- **Default:** `[]`
- **Action:** global variables to declare [Documentation](https://github.com/feross/standard#standardlintfilesfiles-opts-callback).

#### options.plugins

- **Type:** `Array`
- **Default:** `[]`
- **Action:** eslint plugins [Documentation](https://github.com/feross/standard#standardlintfilesfiles-opts-callback).

#### options.envs

- **Type:** `Array`
- **Default:** `[]`
- **Action:** eslint environment [Valid Values](https://github.com/sindresorhus/globals/blob/master/globals.json).

#### options.parser

- **Type:** `Array`
- **Default:** `''`
- **Action:** js parser (e.g. babel-eslint) [Documentation](https://github.com/feross/standard#standardlintfilesfiles-opts-callback).

In this example, the `fix` option is set to `true` so the source files will be auto-formatted (and written back to disk) before being linted:

```javascript
grunt.initConfig({
standard: {
options: {
format: true
fix: true
},
app: {
src: [
Expand All @@ -86,8 +109,4 @@ grunt.initConfig({
})
```

## Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using [Grunt](http://gruntjs.com/).

## Release History
_(Nothing yet)_
## [Contribute](CONTRIBUTE.md)
11 changes: 0 additions & 11 deletions lib/formatter.js

This file was deleted.

Loading

0 comments on commit 29c5343

Please sign in to comment.