🌟 JavaScript Style Guide, with linter & automatic code fixer

Overview

Standard - JavaScript Style Guide
JavaScript Standard Style

discord status badge Node tests status badge old Node test npm version npm downloads Standard - JavaScript Style Guide

Sponsored by    Speakeasy

EnglishEspañol (Latinoamérica)FrançaisBahasa IndonesiaItaliano (Italian)日本語 (Japanese)한국어 (Korean)Português (Brasil)简体中文 (Simplified Chinese)繁體中文 (Taiwanese Mandarin)

JavaScript style guide, linter, and formatter

This module saves you (and others!) time in three ways:

  • No configuration. The easiest way to enforce code quality in your project. No decisions to make. No .eslintrc files to manage. It just works.
  • Automatically format code. Just run standard --fix and say goodbye to messy or inconsistent code.
  • Catch style issues & programmer errors early. Save precious code review time by eliminating back-and-forth between reviewer & contributor.

Give it a try by running npx standard --fix right now!

Table of Contents

Install

The easiest way to use JavaScript Standard Style is to install it globally as a Node command line program. Run the following command in Terminal:

$ npm install standard --global

Or, you can install standard locally, for use in a single project:

$ npm install standard --save-dev

Note: To run the preceding commands, Node.js and npm must be installed.

Usage

After you've installed standard, you should be able to use the standard program. The simplest use case would be checking the style of all JavaScript files in the current working directory:

$ standard
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.

If you've installed standard locally, run with npx instead:

$ npx standard

You can optionally pass in a directory (or directories) using the glob pattern. Be sure to quote paths containing glob patterns so that they are expanded by standard instead of your shell:

$ standard "src/util/**/*.js" "test/**/*.js"

Note: by default standard will look for all files matching the patterns: **/*.js, **/*.jsx.

What you might do if you're clever

  1. Add it to package.json

    {
      "name": "my-cool-package",
      "devDependencies": {
        "standard": "*"
      },
      "scripts": {
        "test": "standard && node my-tests.js"
      }
    }
  2. Style is checked automatically when you run npm test

    $ npm test
    Error: Use JavaScript Standard Style
      lib/torrent.js:950:11: Expected '===' and instead saw '=='.
  3. Never give style feedback on a pull request again!

Why should I use JavaScript Standard Style?

The beauty of JavaScript Standard Style is that it's simple. No one wants to maintain multiple hundred-line style configuration files for every module/project they work on. Enough of this madness!

This module saves you (and others!) time in three ways:

  • No configuration. The easiest way to enforce consistent style in your project. Just drop it in.
  • Automatically format code. Just run standard --fix and say goodbye to messy or inconsistent code.
  • Catch style issues & programmer errors early. Save precious code review time by eliminating back-and-forth between reviewer & contributor.

Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier.

For more info, see the conference talk "Write Perfect Code with Standard and ESLint". In this talk, you'll learn about linting, when to use standard versus eslint, and how prettier compares to standard.

Who uses JavaScript Standard Style?

Free MIDIs, MIDI file downloads College essays, AP notes
Your logo here Your logo here Your logo here

In addition to companies, many community members use standard on packages that are too numerous to list here.

standard is also the top-starred linter in GitHub's Clean Code Linter showcase.

Are there text editor plugins?

First, install standard. Then, install the appropriate plugin for your editor:

Sublime Text

Using Package Control, install SublimeLinter and SublimeLinter-contrib-standard.

For automatic formatting on save, install StandardFormat.

Atom

Install linter-js-standard.

Alternatively, you can install linter-js-standard-engine. Instead of bundling a version of standard it will automatically use the version installed in your current project. It will also work out of the box with other linters based on standard-engine.

For automatic formatting, install standard-formatter. For snippets, install standardjs-snippets.

Visual Studio Code

Install vscode-standardjs. (Includes support for automatic formatting.)

For JS snippets, install: vscode-standardjs-snippets. For React snippets, install vscode-react-standard.

Vim

Install ale. And add these lines to your .vimrc file.

let g:ale_linters = {
\   'javascript': ['standard'],
\}
let g:ale_fixers = {'javascript': ['standard']}

This sets standard as your only linter and fixer for javascript files and so prevents conflicts with eslint. For linting and automatic fixing on save, add these lines to .vimrc:

let g:ale_lint_on_save = 1
let g:ale_fix_on_save = 1

Alternative plugins to consider include neomake and syntastic, both of which have built-in support for standard (though configuration may be necessary).

Emacs

Install Flycheck and check out the manual to learn how to enable it in your projects.

Brackets

Search the extension registry for "Standard Code Style" and click "Install".

WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains, etc.)

WebStorm recently announced native support for standard directly in the IDE.

If you still prefer to configure standard manually, follow this guide. This applies to all JetBrains products, including PhpStorm, IntelliJ, RubyMine, etc.

Is there a readme badge?

Yes! If you use standard in your project, you can include one of these badges in your readme to let people know that your code is using the standard style.

JavaScript Style Guide

[![JavaScript Style Guide](https://cdn.rawgit.com/standard/standard/master/badge.svg)](https://github.com/standard/standard)

JavaScript Style Guide

[![JavaScript Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://standardjs.com)

I disagree with rule X, can you change it?

No. The whole point of standard is to save you time by avoiding bikeshedding about code style. There are lots of debates online about tabs vs. spaces, etc. that will never be resolved. These debates just distract from getting stuff done. At the end of the day you have to 'just pick something', and that's the whole philosophy of standard -- its a bunch of sensible 'just pick something' opinions. Hopefully, users see the value in that over defending their own opinions.

There are a couple of similar packages for anyone who does not want to completely accept standard:

If you really want to configure hundreds of ESLint rules individually, you can always use eslint directly with eslint-config-standard to layer your changes on top. standard-eject can help you migrate from standard to eslint and eslint-config-standard.

Pro tip: Just use standard and move on. There are actual real problems that you could spend your time solving! :P

But this isn't a real web standard!

Of course it's not! The style laid out here is not affiliated with any official web standards groups, which is why this repo is called standard/standard and not ECMA/standard.

The word "standard" has more meanings than just "web standard" :-) For example:

  • This module helps hold our code to a high standard of quality.
  • This module ensures that new contributors follow some basic style standards.

Is there an automatic formatter?

Yes! You can use standard --fix to fix most issues automatically.

standard --fix is built into standard for maximum convenience. Most problems are fixable, but some errors (like forgetting to handle errors) must be fixed manually.

To save you time, standard outputs the message "Run standard --fix to automatically fix some problems" when it detects problems that can be fixed automatically.

How do I ignore files?

Certain paths (node_modules/, coverage/, vendor/, *.min.js, and files/folders that begin with . like .git/) are automatically ignored.

Paths in a project's root .gitignore file are also automatically ignored.

Sometimes you need to ignore additional folders or specific minified files. To do that, add a standard.ignore property to package.json:

"standard": {
  "ignore": [
    "**/out/",
    "/lib/select2/",
    "/lib/ckeditor/",
    "tmp.js"
  ]
}

How do I disable a rule?

In rare cases, you'll need to break a rule and hide the error generated by standard.

JavaScript Standard Style uses ESLint under-the-hood and you can hide errors as you normally would if you used ESLint directly.

To get verbose output (so you can find the particular rule name to ignore), run:

$ standard --verbose
Error: Use JavaScript Standard Style
  routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)

Disable all rules on a specific line:

file = 'I know what I am doing' // eslint-disable-line

Or, disable only the "no-use-before-define" rule:

file = 'I know what I am doing' // eslint-disable-line no-use-before-define

Or, disable the "no-use-before-define" rule for multiple lines:

/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */

I use a library that pollutes the global namespace. How do I prevent "variable is not defined" errors?

Some packages (e.g. mocha) put their functions (e.g. describe, it) on the global object (poor form!). Since these functions are not defined or require'd anywhere in your code, standard will warn that you're using a variable that is not defined (usually, this rule is really useful for catching typos!). But we want to disable it for these global variables.

To let standard (as well as humans reading your code) know that certain variables are global in your code, add this to the top of your file:

/* global myVar1, myVar2 */

If you have hundreds of files, it may be desirable to avoid adding comments to every file. In this case, run:

$ standard --global myVar1 --global myVar2

Or, add this to package.json:

{
  "standard": {
    "globals": [ "myVar1", "myVar2" ]
  }
}

Note: global and globals are equivalent.

How do I use experimental JavaScript (ES Next) features?

standard supports the latest ECMAScript features, ES8 (ES2017), including language feature proposals that are in "Stage 4" of the proposal process.

To support experimental language features, standard supports specifying a custom JavaScript parser. Before using a custom parser, consider whether the added complexity is worth it.

To use a custom parser, first install it from npm:

npm install @babel/eslint-parser --save-dev

Then run:

$ standard --parser @babel/eslint-parser

Or, add this to package.json:

{
  "standard": {
    "parser": "@babel/eslint-parser"
  }
}

Can I use a JavaScript language variant, like Flow or TypeScript?

standard supports the latest ECMAScript features. However, Flow and TypeScript add new syntax to the language, so they are not supported out-of-the-box.

For TypeScript, an official variant ts-standard is supported and maintained that provides a very similar experience to standard.

For other JavaScript language variants, standard supports specifying a custom JavaScript parser as well as an ESLint plugin to handle the changed syntax. Before using a JavaScript language variant, consider whether the added complexity is worth it.

TypeScript

ts-standard is the officially supported variant for TypeScript. ts-standard supports all the same rules and options as standard and includes additional TypeScript specific rules. ts-standard will even lint regular javascript files by setting the configuration in tsconfig.json.

npm install ts-standard --save-dev

Then run (where tsconfig.json is located in the working directory):

$ ts-standard

Or, add this to package.json:

{
  "ts-standard": {
    "project": "./tsconfig.json"
  }
}

Note: To include additional files in linting such as test files, create a tsconfig.eslint.json file to use instead.

If you really want to configure hundreds of ESLint rules individually, you can always use eslint directly with eslint-config-standard-with-typescript to layer your changes on top.

Flow

To use Flow, you need to run standard with @babel/eslint-parser as the parser and eslint-plugin-flowtype as a plugin.

npm install @babel/eslint-parser eslint-plugin-flowtype --save-dev

Then run:

$ standard --parser @babel/eslint-parser --plugin flowtype

Or, add this to package.json:

{
  "standard": {
    "parser": "@babel/eslint-parser",
    "plugins": [ "flowtype" ]
  }
}

Note: plugin and plugins are equivalent.

What about Mocha, Jest, Jasmine, QUnit, etc?

To support mocha in test files, add this to the top of the test files:

/* eslint-env mocha */

Or, run:

$ standard --env mocha

Where mocha can be one of jest, jasmine, qunit, phantomjs, and so on. To see a full list, check ESLint's specifying environments documentation. For a list of what globals are available for these environments, check the globals npm module.

Note: env and envs are equivalent.

What about Web Workers and Service Workers?

Add this to the top of web worker files:

/* eslint-env worker */

This lets standard (as well as humans reading the code) know that self is a global in web worker code.

For Service workers, add this instead:

/* eslint-env serviceworker */

What is the difference between warnings and errors?

standard treats all rule violations as errors, which means that standard will exit with a non-zero (error) exit code.

However, we may occasionally release a new major version of standard which changes a rule that affects the majority of standard users (for example, transitioning from var to let/const). We do this only when we think the advantage is worth the cost and only when the rule is auto-fixable.

In these situations, we have a "transition period" where the rule change is only a "warning". Warnings don't cause standard to return a non-zero (error) exit code. However, a warning message will still print to the console. During the transition period, using standard --fix will update your code so that it's ready for the next major version.

The slow and careful approach is what we strive for with standard. We're generally extremely conservative in enforcing the usage of new language features. We want using standard to be light and fun and so we're careful about making changes that may get in your way. As always, you can disable a rule at any time, if necessary.

Can I check code inside of Markdown or HTML files?

To check code inside Markdown files, use standard-markdown.

Alternatively, there are ESLint plugins that can check code inside Markdown, HTML, and many other types of language files:

To check code inside Markdown files, use an ESLint plugin:

$ npm install eslint-plugin-markdown

Then, to check JS that appears inside code blocks, run:

$ standard --plugin markdown '**/*.md'

To check code inside HTML files, use an ESLint plugin:

$ npm install eslint-plugin-html

Then, to check JS that appears inside <script> tags, run:

$ standard --plugin html '**/*.html'

Is there a Git pre-commit hook?

Yes! Hooks are great for ensuring that unstyled code never even makes it into your repo. Never give style feedback on a pull request again!

You even have a choice...

Install your own hook

#!/bin/bash

# Ensure all JavaScript files staged for commit pass standard code style
function xargs-r() {
  # Portable version of "xargs -r". The -r flag is a GNU extension that
  # prevents xargs from running if there are no input files.
  if IFS= read -r -d $'\n' path; then
    echo "$path" | cat - | xargs "[email protected]"
  fi
}
git diff --name-only --cached --relative | grep '\.jsx\?$' | sed 's/[^[:alnum:]]/\\&/g' | xargs-r -E '' -t standard
if [[ $? -ne 0 ]]; then
  echo 'JavaScript Standard Style errors were detected. Aborting commit.'
  exit 1
fi

Use a pre-commit hook

The pre-commit library allows hooks to be declared within a .pre-commit-config.yaml configuration file in the repo, and therefore more easily maintained across a team.

Users of pre-commit can simply add standard to their .pre-commit-config.yaml file, which will automatically fix .js, .jsx, .ts, .tsx, .mjs and .cjs files:

  - repo: https://github.com/standard/standard
    rev: master
    hooks:
      - id: standard

Alternatively, for more advanced styling configurations, use standard within the eslint hook:

  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: master
    hooks:
      - id: eslint
        files: \.[jt]sx?$  # *.js, *.jsx, *.ts and *.tsx
        types: [file]
        additional_dependencies:
          - [email protected]
          - [email protected]
          # and whatever other plugins...

How do I make the output all colorful and pretty?

The built-in output is simple and straightforward, but if you like shiny things, install snazzy:

$ npm install snazzy

And run:

$ standard --verbose | snazzy

There's also standard-tap, standard-json, standard-reporter, and standard-summary.

Is there a Node.js API?

Yes!

standard.lintText(text, [opts], callback)

Lint the provided source text. An opts object may be provided:

{
  cwd: '',      // current working directory (default: process.cwd())
  filename: '', // path of the file containing the text being linted (optional, though some eslint plugins require it)
  fix: false,   // automatically fix problems
  globals: [],  // custom global variables to declare
  plugins: [],  // custom eslint plugins
  envs: [],     // custom eslint environment
  parser: ''    // custom js parser (e.g. @babel/eslint-parser)
}

Additional options may be loaded from a package.json if it's found for the current working directory.

The callback will be called with an Error and results object.

The results object will contain the following properties:

var results = {
  results: [
    {
      filePath: '',
      messages: [
        { ruleId: '', message: '', line: 0, column: 0 }
      ],
      errorCount: 0,
      warningCount: 0,
      output: '' // fixed source code (only present with {fix: true} option)
    }
  ],
  errorCount: 0,
  warningCount: 0
}

results = standard.lintTextSync(text, [opts])

Synchronous version of standard.lintText(). If an error occurs, an exception is thrown. Otherwise, a results object is returned.

standard.lintFiles(files, [opts], callback)

Lint the provided files globs. An opts object may be provided:

var opts = {
  ignore: [],   // file globs to ignore (has sane defaults)
  cwd: '',      // current working directory (default: process.cwd())
  fix: false,   // automatically fix problems
  globals: [],  // global variables to declare
  plugins: [],  // eslint plugins
  envs: [],     // eslint environment
  parser: ''    // js parser (e.g. @babel/eslint-parser)
}

The callback will be called with an Error and results object (same as above).

How do I contribute to StandardJS?

Contributions are welcome! Check out the issues or the PRs, and make your own if you want something that you don't see there.

Want to chat? Join contributors on IRC in the #standard channel on freenode.

Here are some important packages in the standard ecosystem:

There are also many editor plugins, a list of npm packages that use standard, and an awesome list of packages in the standard ecosystem.

Security Policies and Procedures

The standard team and community take all security bugs in standard seriously. Please see our security policies and procedures document to learn how to report issues.

License

MIT. Copyright (c) Feross Aboukhadijeh.

Comments
  • npm install funding

    npm install funding

    The experiment is over – read the recap here!

    Hey folks! 👋

    I've already spoken to a few of you about this idea, but I'd like to share it with the broader community now that standard 14 has shipped.

    Background: I think that the current model of sustaining open source is not working and we need more experimentation. This is one such experiment.

    What's the experiment? Whenever standard 14 is installed, we'll display a message from a company that supports open source. The sponsorship pays directly for maintainer time. That is, writing new features, fixing bugs, answering user questions, and improving documentation.

    What's the goal? My goal with this experiment is to make standard healthier. If we learn that the experiment works, perhaps we can help make all open source healthier, too. For complex reasons, companies are generally hesitant or unwilling to fund OSS directly. When it does happen, it's never enough and it never reaches packages which are transitive dependencies (i.e. packages that no one installs explicitly and therefore no one knows exists). Essentially, we have a public good which is consumed by huge numbers of users, but which almost no one pays for. Fortunately, there exists a funding model that usually works for public goods like this – ads. The goal of this experiment is to answer the question: Can we use ethical ads – ads that don't track users or collect data – to fund open source software?

    What does the code do? The code for this experiment is available here: feross/funding. Essentially, it calls console.log() on some text. There is no tracking, data collecting, or unexpected behavior. You can look at the code to verify – indeed, this is the beauty of open source!

    What will the funds be used for? The funds raised so far ($2,000) have paid for Feross's time to release Standard 14 which has taken around five days. If we are able to raise additional funds, the next thing I'd like to focus on is out-of-the-box TypeScript support in StandardJS (one of the most common feature requests!) and modernizing the various text editor plugins (many of which are currently unmaintained). If others in the community are interested in taking the lead on any of these issues, I'd like to direct some funds to you.

    Feedback welcome!


    EDIT: This thread is now locked :lock:

    For why + next steps, scroll to the end >>

    EDIT: The experiment is over – Feross posted a recap on his blog

    meta 
    opened by feross 174
  • Release proposal: standard v8

    Release proposal: standard v8

    Planned release date: September 1, 2016. (approx. 45 days from the date of this issue)

    New features

    • [x] Upgrade to ESLint v3 (http://eslint.org/docs/user-guide/migrating-to-3.0.0) (https://github.com/feross/standard/pull/565)
      • BREAKING: Drop support for node < 4 (this was a decision made by the ESLint team)
    • [x] Expose ESLint's --fix command line flag (https://github.com/feross/standard/issues/540) (https://github.com/Flet/standard-engine/issues/107)
      • Lightweight, no additional dependencies, fixes dozens of rules automatically

    New rules

    (Estimated % of affected standard users, based on test suite in parens)

    • [x] Enforce placing object properties on separate lines (object-property-newline) (https://github.com/feross/standard/issues/524) (2%)
    • [x] Require block comments to be balanced (spaced-comment "balanced") (https://github.com/feross/standard/issues/572) (2%)
    • [x] Disallow constant expressions in conditions (no-constant-condition) (https://github.com/feross/standard/issues/563) (1%)
    • [x] Disallow renaming import, export, and destructured assignments to the same name (no-useless-rename) (https://github.com/feross/standard/issues/537) (0%)
    • [x] Disallow spacing between rest and spread operators and their expressions (rest-spread-spacing) (https://github.com/feross/standard/issues/567) (0%)
    • [x] Disallow the Unicode Byte Order Mark (BOM) (unicode-bom) (https://github.com/feross/standard/issues/538) (0%)
    • [x] Disallow assignment to native objects/global variables (no-global-assign) (https://github.com/feross/standard/issues/596) (0%)
    • [x] Disallow negating the left operand of relational operators (no-unsafe-negation) (https://github.com/feross/standard/issues/595) (0%)
    • [x] Disallow template literal placeholder syntax in regular strings (no-template-curly-in-string) (https://github.com/feross/standard/issues/594) (0%)
    • [x] Disallow tabs in file (no-tabs) (https://github.com/feross/standard/issues/593) (0%)

    Changed rules

    • [x] ~~Enforce use of double quotes in JSX attributes (jsx-quotes) (1%, but likely more in private repos)~~
      • ~~BREAKING: This rule was changed to reflect the way the vast majority of developers quote HTML attributes (both in plain HTML and in the React community) (https://github.com/feross/eslint-config-standard/issues/27)~~
      • This rule was re-evaluated. See https://github.com/feross/standard/issues/564#issuecomment-240631820
    • [x] Relax rule: Allow template literal strings (backtick strings) to avoid escaping
 (https://github.com/feross/standard/issues/421)
    • [x] Relax rule: Do not enforce spacing around * in generator functions (https://github.com/feross/standard/issues/564#issuecomment-234699126)
      • This is a temporary workaround for babel users who use async generator functions.

    Internal changes

    • [x] Migrate to new ESLint rule format for plugins (https://github.com/xjamundx/eslint-plugin-standard/pull/11) (https://github.com/xjamundx/eslint-plugin-promise/pull/19)
    meta 
    opened by feross 71
  • Fat arrow method definitions

    Fat arrow method definitions

    Is disallowing defining methods via fat arrows a rule or a bug? This is valid syntax with babel and I'm using babel-eslint but the rule is no-undef which I believe is wrong.

    image

    This is really helpful because it auto-binds this to the component instance. If you were to use the non fat arrow syntax, you would need to manually bind this to that method.

    This is enabled by the transform-class-properties babel plugin which i have enabled in my .babelrc

    {
      "presets": [
        "stage-0",
      	["es2015", {"modules": false}],
      	"react"
      ],
      "plugins": [
        "transform-class-properties"
      ]
    }
    
    opened by dadamssg 52
  • Different settings for different JS versions

    Different settings for different JS versions

    I think it would make sense for some settings to differ based on which JS version is targeted:

    Of course it would be the best if compatibility is kept (a JS3 code is compatible with JS3 up to JS6 config).

    I don't know what would be the best way to implement that, maybe via an options in package.json:

    {
      "standard": {
        "compatibility": "es2015"
      }
    }
    
    question stale 
    opened by julien-f 51
  • idea: standard-readme

    idea: standard-readme

    I use standard to check my code, dependency-check to check my package.json deps are sane, but I don't have anything to check my readme.

    I wonder if it would practical to do for node module readmes what standard did for JS style. There is a pretty cool markdown linter called markdownlint that could be used for basic style checking.

    Going beyond style, though, what about failing if these cases are not met:

    • readme must have a title
    • title must be followed by a description
    • description must be followed by a nodei.co badge
    • readme must have a section titled installation
    • readme must have a section titled example or usage
    • readme must have a section titled api
    • api section must have a sub section for each public method in the modules main entry
    • readme must have a section titled license

    so, does this seem like a good idea? what are other base requirements that should be added (or removed) from the above list?

    question 
    opened by maxogden 49
  • Which companies are using `standard`?

    Which companies are using `standard`?

    If you use standard at your company or organization, please leave a comment here. Include a link to proof, if you can!

    Context: I just got a message from someone trying to convince his co-workers to adopt standard. He asked for a list of companies who are currently using standard to make them feel more comfortable. Then I realized that we don't actually have such a list. Let's make one!

    meta 
    opened by feross 46
  • Object destructuring spacing

    Object destructuring spacing

    var { x} = ...
    var {x} = ...
    var {x } = ...
    

    These cases probably shouldn't be allowed. I'm in favour of what we've done elsewhere, enforce the spaces either side.

    In any case, consistency, thoughts?

    enhancement 
    opened by dcousens 46
  • Adopt eslint-config-standard-with-typescript

    Adopt eslint-config-standard-with-typescript

    opened by mightyiam 44
  • Remove no-return-await as it sets traps during code refactoring and causes inferior stack traces

    Remove no-return-await as it sets traps during code refactoring and causes inferior stack traces

    What version of this package are you using? 14.3.1

    What problem do you want to solve? The no-return-await rule introduced in #695 is the only one with which I continue to disagree, and I think since the arrival of async stack traces in Node, there is now another reason to rethink it.

    Therefore I want to open a discussion here. My point is that the no-return-await rule (which disallows "redundant" use of return await promise) has two negative effects:

    1) It reduces the usefulness of error stack traces

    Node now has zero-cost async stack traces with the --async-stack-traces flag. There, it makes a difference whether return promise or return await promise is used - the former omits a stack frame.

    Example:

    const delay = require('util').promisify(setTimeout)
    const throws = async () => { await delay(100); throw new Error('oh noez') }
    
    const a = async () => { return throws() }
    const b = async () => { return await throws() }
    
    async function main () {
        try { await a() } catch (e) { console.error(e) }
        try { await b() } catch (e) { console.error(e) }
    }
    
    main()
    

    Result:

    [email protected]:~/z/Temp $ node --async-stack-traces example.js
    Error: oh noez
        at throws (/mnt/c/Users/david/Temp/example.js:2:54)
        at async main (/mnt/c/Users/david/Temp/example.js:8:8)
    Error: oh noez
        at throws (/mnt/c/Users/david/Temp/example.js:2:54)
        at async b (/mnt/c/Users/david/Temp/example.js:5:32)
        at async main (/mnt/c/Users/david/Temp/example.js:9:8)
    

    Note how there is no stack frame for a.

    2) It lays out a trap for code refactoring by making it easy to overlook that an async function is being called

    Example with subtle unintended behavior:

    return somethingAsync()
    // refactor to
    try {
      return somethingAsync()
    } catch (e) {
      // ...
    }
    // whoops, now suddenly it makes a difference - errors are caught only
    // if they happen in the synchronous part of `somethingAsync` - hard to spot!
    

    Example with more obvious unintended behavior:

    return somethingAsync()
    // refactor to
    return somethingAsync() || null
    // whoops, that did nothing, because the promise won't be null
    

    Another example:

    return somethingAsync()
    // refactor to
    const value = somethingAsync()
    await moreStuff()
    return value
    // whoops now somethingAsync runs in parallel to moreStuff, which
    // may not be immediately obvious and cause a race condition
    

    Or even:

    return somethingAsync()
    // refactor to
    return { value: somethingAsync() }
    // whoops now the outer code gets a promise in an unexpected place
    // and if it previously was a boolean, it may not even be noticed, but
    // conditions will now get always a truthy value...!
    

    There are many more examples like this which don't immediately crash (it is easy to spot something like somethingAsync().toUpperCase() is not a function, but my examples above are more subtle). If I modify existing code, I may not be familiar with every function that is being called (and I may even use a refactor tool where I just select the returned value and extract to a variable for example). Usually, I'd easily recognize that await somethingAsync() should probably stay this way, but with return somethingAsync() I may not realize that in any place other than the return statement, I'd need an await in front (and even if it stays in a return, other things like the aforementioned try block may suddenly require a change here - and imagine that the return is somewhere inside a larger block of code which I'm now wrapping with try)!

    I had all of these issues from my examples happen in real life.

    To work around this issue, I manually mark return somethingAsync() with a comment, e.g. return somethingAsync() // async but that seems ugly and much less useful than having the obvious await there (plus, it doesn't solve the try case).

    What do you think?

    What do you think is the correct solution to this problem? Remove the no-return-await rule

    Are you willing to submit a pull request to implement this change? I guess so...? (but I guess it would be easier for you)

    opened by CherryDT 43
  • “No semicolons” is the opposite of practical

    “No semicolons” is the opposite of practical

    Adopting standard style means ranking the importance of community conventions higher than personal style.

    README

    I assume a standard that calls itself “standard” would choose “practical” over “fancy” every time. It does so, except when it comes to semicolons.

    Consider these two rules:

    • No semicolons – It's fine. Really!
    • Never start a line with ( or [

    They can be substituted by one simpler rule:

    • Always put semicolons between statements.

    The “never start a line with ( or [” rule is very arbitrary. It is only going to get worse with ES6 where

    [a, b] = something();
    

    is a valid destructuring construction.

    Isn't it strange to write

    { a, b } = something()
    ;[a, b] = something()
    

    thus making code less uniform, if you can make it more uniform by just writing semicolons?

    { a, b } = something();
    [a, b] = something();
    

    I understand you probably have feelings about this subject, so I don't really expect this to be considered.

    Still, it is unfortunate for the subjective aesthetics to triumph over the objective simplicity in something called a “standard”.

    opened by gaearon 43
  • parentheses around arrow function single argument

    parentheses around arrow function single argument

    Standard makes to wrap with parentheses single argument in simple cases:

    [1, 2, 3].map((number) => `A string containing the ${number}.`)
    

    and even the simpliest (which are very popular in functional/streams programming)

    some.filter((x) => x)
    // or
    some.flatMap((_) => _)
    

    this seems to me more readable and doesn't break consitency:

    some.filter(x => x)
    // or
    some.flatMap(_ => _)
    

    arbnb has the same request a while ago (https://github.com/airbnb/javascript/issues/281) and they eventually changed it: https://github.com/airbnb/javascript#arrow-functions to accomodate simplier cases.

    I think it would be reasonable to do.

    question 
    opened by wclr 42
  • build(deps): update eslint requirement from ^8.13.0 to ^8.24.0

    build(deps): update eslint requirement from ^8.13.0 to ^8.24.0

    Updates the requirements on eslint to permit the latest version.

    Release notes

    Sourced from eslint's releases.

    v8.24.0

    Features

    • 1729f9e feat: account for sourceType: "commonjs" in the strict rule (#16308) (Milos Djermanovic)
    • b0d72c9 feat: add rule logical-assignment-operators (#16102) (fnx)
    • f02bcd9 feat: array-callback-return support findLast and findLastIndex (#16314) (Sosuke Suzuki)

    Documentation

    • 2c152ff docs: note false positive Object.getOwnPropertyNames in prefer-reflect (#16317) (AnnAngela)
    • bf7bd88 docs: fix warn severity description for new config files (#16324) (Nitin Kumar)
    • 8cc0bbe docs: use more clean link syntax (#16309) (Percy Ma)
    • 6ba269e docs: fix typo (#16288) (jjangga0214)

    Chores

    • 131e646 chore: Upgrade @​humanwhocodes/config-array for perf (#16339) (Nicholas C. Zakas)
    • 504fe59 perf: switch from object spread to Object.assign when merging globals (#16311) (Milos Djermanovic)
    Changelog

    Sourced from eslint's changelog.

    v8.24.0 - September 23, 2022

    • 131e646 chore: Upgrade @​humanwhocodes/config-array for perf (#16339) (Nicholas C. Zakas)
    • 2c152ff docs: note false positive Object.getOwnPropertyNames in prefer-reflect (#16317) (AnnAngela)
    • bf7bd88 docs: fix warn severity description for new config files (#16324) (Nitin Kumar)
    • 504fe59 perf: switch from object spread to Object.assign when merging globals (#16311) (Milos Djermanovic)
    • 1729f9e feat: account for sourceType: "commonjs" in the strict rule (#16308) (Milos Djermanovic)
    • b0d72c9 feat: add rule logical-assignment-operators (#16102) (fnx)
    • f02bcd9 feat: array-callback-return support findLast and findLastIndex (#16314) (Sosuke Suzuki)
    • 8cc0bbe docs: use more clean link syntax (#16309) (Percy Ma)
    • 6ba269e docs: fix typo (#16288) (jjangga0214)

    v8.23.1 - September 12, 2022

    • b719893 fix: Upgrade eslintrc to stop redefining plugins (#16297) (Brandon Mills)
    • 734b54e fix: improve autofix for the prefer-const rule (#16292) (Nitin Kumar)
    • 6a923ff fix: Ensure that glob patterns are normalized (#16287) (Nicholas C. Zakas)
    • 38e8171 perf: migrate rbTree to js-sdsl (#16267) (Zilong Yao)
    • 16cba3f docs: fix mobile double tap issue (#16293) (Sam Chen)
    • c6900f8 fix: Ensure globbing doesn't include subdirectories (#16272) (Nicholas C. Zakas)
    • e098b5f docs: keyboard control to search results (#16222) (Shanmughapriyan S)
    • 1b5b2a7 docs: add Consolas font and prioritize resource loading (#16225) (Amaresh S M)
    • 1c388fb chore: switch nyc to c8 (#16263) (唯然)
    • 67db10c chore: enable linting .eleventy.js again (#16274) (Milos Djermanovic)
    • 1ae8236 docs: copy & use main package version in docs on release (#16252) (Jugal Thakkar)
    • 42bfbd7 chore: fix npm run perf crashes (#16258) (唯然)
    • 279f0af docs: Improve id-denylist documentation (#16223) (Mert Ciflikli)

    v8.23.0 - August 26, 2022

    • 2e004ab chore: upgrade @​eslint/eslintrc@​1.3.1 (#16249) (Milos Djermanovic)
    • d35fbbe chore: Upgrade to [email protected] (#16243) (Milos Djermanovic)
    • 3e5839e feat: Enable eslint.config.js lookup from CLI (#16235) (Nicholas C. Zakas)
    • 30b1a2d feat: add allowEmptyCase option to no-fallthrough rule (#15887) (Amaresh S M)
    • ed26229 test: add no-extra-parens tests with rest properties (#16236) (Milos Djermanovic)
    • deaf69f chore: fix off-by-one min-width: 1023px media queries (#15974) (Milos Djermanovic)
    • 63dec9f refactor: simplify parseListConfig (#16241) (Milos Djermanovic)
    • 43f03aa feat: no-warning-comments support comments with decoration (#16120) (Lachlan Hunt)
    • b1918da docs: package.json conventions (#16206) (Patrick McElhaney)
    • 0e03c33 docs: remove word immediately (#16217) (Strek)
    • c6790db docs: add anchor link for "migrating from jscs" (#16207) (Percy Ma)
    • 7137344 docs: auto-generation edit link (#16213) (Percy Ma)

    v8.22.0 - August 13, 2022

    • 2b97607 feat: Implement caching for FlatESLint (#16190) (Nicholas C. Zakas)
    • fd5d3d3 feat: add methodsIgnorePattern option to object-shorthand rule (#16185) (Milos Djermanovic)
    • 9f5a752 docs: optimize image assets (#16170) (Sam Chen)
    • 61b2948 docs: add svgo command to pre commit hook (#16178) (Amaresh S M)
    • 784096d docs: improve search result UI (#16187) (Sam Chen)

    ... (truncated)

    Commits
    • a578780 8.24.0
    • f2cfacd Build: changelog update for 8.24.0
    • 131e646 chore: Upgrade @​humanwhocodes/config-array for perf (#16339)
    • 2c152ff docs: note false positive Object.getOwnPropertyNames in prefer-reflect (#16...
    • bf7bd88 docs: fix warn severity description for new config files (#16324)
    • 504fe59 perf: switch from object spread to Object.assign when merging globals (#16311)
    • 1729f9e feat: account for sourceType: "commonjs" in the strict rule (#16308)
    • b0d72c9 feat: add rule logical-assignment-operators (#16102)
    • f02bcd9 feat: array-callback-return support findLast and findLastIndex (#16314)
    • 8cc0bbe docs: use more clean link syntax (#16309)
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependency 
    opened by dependabot[bot] 0
  • build(deps): update eslint-plugin-n requirement from ^15.1.0 to ^15.3.0

    build(deps): update eslint-plugin-n requirement from ^15.1.0 to ^15.3.0

    Updates the requirements on eslint-plugin-n to permit the latest version.

    Release notes

    Sourced from eslint-plugin-n's releases.

    Release 15.3.0

    • feat: Added supported version for module imports(13.2.0) (#52) (98b873a)
    Commits

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependency 
    opened by dependabot[bot] 0
  • build(deps-dev): update tape requirement from ^5.5.3 to ^5.6.1

    build(deps-dev): update tape requirement from ^5.5.3 to ^5.6.1

    Updates the requirements on tape to permit the latest version.

    Changelog

    Sourced from tape's changelog.

    v5.6.1 - 2022-09-19

    Commits

    • [eslint] fix indentation 2151e06
    • [meta] add auto-changelog 86cbbd1
    • [eslint] enforce no-use-before-define f8a8a7f
    • [meta] fix repo URLs a9ae3c2
    • [Tests] stackTrace: use the common getDiag utility 298cb80
    • [eslint] enable func-style 98b9623
    • [New] bin/tape: include the exact arg when there are no glob results; use require on --require files 6a1ce43
    • [eslint] clean up config a bit 67ad201
    • [meta] create FUNDING.yml 5b4752f
    • [Refactor] bin/tape: make it a bit more functional, for easier v5 backporting fbdbfc9
    • [Deps] update glob, object-inspect, resolve, string.prototype.trim 6a3c200
    • [Dev Deps] update @ljharb/eslint-config, array.prototype.flatmap, es-value-fixtures, falafel 934d49b
    • [Tests] fix no_only tests on Windows f35f71b
    • Revert "[Tests] handle a broken error cause in node 16.9/16.10" 23fac16
    • [Robustness] test observably looks up exec on the object 4575ca4
    • [meta] add SECURITY.md 7b0c901
    • [meta] add missing npmrc config 5d11d84
    • [Deps] update object.assign 3327fdd
    • [readme] fix version badge 74e6c9e
    • Merge tag 'v4.16.0' 4a44a7e

    v5.6.0 - 2022-08-16

    Commits

    • [Tests] handle a broken error cause in node 16.9/16.10 53d9e18
    • [meta] use npmignore to autogenerate an npmignore file 12cc602
    • [New] bin/tape: include the exact arg when there are no glob results; use require.resolve on --require files e23ec12
    • [meta] create FUNDING.yml f7e3161
    • [Robustness] test observably looks up exec on the object 9dbe9ad
    • [meta] remove unused travis.yml file 5a52443
    • [Deps] update glob, object-inspect, object.assign f6f39a2
    • [Dev Deps] update @ljharb/eslint-config, array.prototype.flatmap, es-value-fixtures 6bc8c38
    • [meta] ensure prelint works on windows 48896e8
    • [Tests] fix no_only tests on Windows 3e7b2ae
    • [Robustness] test observably looks up exec on the object 330f8d5
    • [Dev Deps] update eslint, @ljharb/eslint-config 3960ccf
    • [meta] add SECURITY.md 7d31894
    • [meta] improve prelint script when no .git dir is present 7c6dbbd
    • [Dev Deps] update es-value-fixtures 6b8e118
    • [Fix] in node v0.4, stream.pipe returns undefined 83d4da8
    • [Deps] update string.prototype.trim 1a245c6
    • Merge tag 'v4.15.1' b2d547a
    • [Deps] update minimist 64677e0

    v5.5.3 - 2022-04-08

    ... (truncated)

    Commits
    • 996b2a0 v5.6.1
    • 5d11d84 [meta] add missing npmrc config
    • 86cbbd1 [meta] add auto-changelog
    • 3327fdd [Deps] update object.assign
    • 67ad201 [eslint] clean up config a bit
    • 98b9623 [eslint] enable func-style
    • f8a8a7f [eslint] enforce no-use-before-define
    • 298cb80 [Tests] stackTrace: use the common getDiag utility
    • 2151e06 [eslint] fix indentation
    • a9ae3c2 [meta] fix repo URLs
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependency 
    opened by dependabot[bot] 0
  • build(deps): update eslint-plugin-react requirement from ^7.28.0 to ^7.31.8

    build(deps): update eslint-plugin-react requirement from ^7.28.0 to ^7.31.8

    Updates the requirements on eslint-plugin-react to permit the latest version.

    Release notes

    Sourced from eslint-plugin-react's releases.

    v7.31.8

    Fixed

    Changed

    #1000: jsx-eslint/eslint-plugin-react#1000 #1002: jsx-eslint/eslint-plugin-react#1002 #1005: jsx-eslint/eslint-plugin-react#1005 #100: jsx-eslint/eslint-plugin-react#100 #1010: jsx-eslint/eslint-plugin-react#1010 #1013: jsx-eslint/eslint-plugin-react#1013 #1022: jsx-eslint/eslint-plugin-react#1022 #1029: jsx-eslint/eslint-plugin-react#1029 #102: jsx-eslint/eslint-plugin-react#102 #1034: jsx-eslint/eslint-plugin-react#1034 #1038: jsx-eslint/eslint-plugin-react#1038 #1041: jsx-eslint/eslint-plugin-react#1041 #1043: jsx-eslint/eslint-plugin-react#1043 #1046: jsx-eslint/eslint-plugin-react#1046 #1047: jsx-eslint/eslint-plugin-react#1047 #1050: jsx-eslint/eslint-plugin-react#1050 #1053: jsx-eslint/eslint-plugin-react#1053 #1057: jsx-eslint/eslint-plugin-react#1057 #105: jsx-eslint/eslint-plugin-react#105 #1061: jsx-eslint/eslint-plugin-react#1061 #1062: jsx-eslint/eslint-plugin-react#1062 #1070: jsx-eslint/eslint-plugin-react#1070 #1071: jsx-eslint/eslint-plugin-react#1071 #1073: jsx-eslint/eslint-plugin-react#1073 #1076: jsx-eslint/eslint-plugin-react#1076 #1079: jsx-eslint/eslint-plugin-react#1079 #1088: jsx-eslint/eslint-plugin-react#1088 #1098: jsx-eslint/eslint-plugin-react#1098 #1101: jsx-eslint/eslint-plugin-react#1101 #1103: jsx-eslint/eslint-plugin-react#1103 #110: jsx-eslint/eslint-plugin-react#110 #1116: jsx-eslint/eslint-plugin-react#1116 #1117: jsx-eslint/eslint-plugin-react#1117 #1119: jsx-eslint/eslint-plugin-react#1119 #1121: jsx-eslint/eslint-plugin-react#1121

    ... (truncated)

    Changelog

    Sourced from eslint-plugin-react's changelog.

    7.31.8 - 2022.09.08

    Fixed

    Changed

    #3425: jsx-eslint/eslint-plugin-react#3425 #3424: jsx-eslint/eslint-plugin-react#3424 #3419: jsx-eslint/eslint-plugin-react#3419 #3416: jsx-eslint/eslint-plugin-react#3416 #3415: jsx-eslint/eslint-plugin-react#3415 #3414: jsx-eslint/eslint-plugin-react#3414 #3413: jsx-eslint/eslint-plugin-react#3413 #3412: jsx-eslint/eslint-plugin-react#3412

    7.31.7 - 2022.09.05

    Fixed

    • [no-unknown-property]: avoid warning on fbt nodes entirely (#3391[] @​ljharb)
    • [no-unknown-property]: add download property support for a and area (#3394[] @​HJain13)
    • [no-unknown-property]: allow webkitAllowFullScreen and mozAllowFullScreen (#3396[] @​ljharb)
    • [no-unknown-property]: controlsList, not controlList (#3397[] @​ljharb)
    • [no-unknown-property]: add more capture event properties (#3402[] @​sjarva)
    • [no-unknown-property]: Add more one word properties found in DefinitelyTyped's react/index.d.ts (#3402[] @​sjarva)
    • [no-unknown-property]: Mark onLoad/onError as supported on iframes (#3398[] @​maiis, #3406[] @​akx)
    • [no-unknown-property]: allow imageSrcSet and imageSizes attributes on <link> (#3407[] @​terrymun)
    • [no-unknown-property]: add border; focusable on <svg> (#3404[] #3404[] @​ljharb)
    • [no-unknown-property]: React lowercases data- attrs (#3395[] @​ljharb)
    • [no-unknown-property]: add valign on table components (#3389[] @​ljharb)

    #3407: jsx-eslint/eslint-plugin-react#3407 #3406: jsx-eslint/eslint-plugin-react#3406 #3405: jsx-eslint/eslint-plugin-react#3405 #3404: jsx-eslint/eslint-plugin-react#3404 #3402: jsx-eslint/eslint-plugin-react#3402 #3398: jsx-eslint/eslint-plugin-react#3398 #3397: jsx-eslint/eslint-plugin-react#3397 #3396: jsx-eslint/eslint-plugin-react#3396 #3395: jsx-eslint/eslint-plugin-react#3395

    ... (truncated)

    Commits
    • 8c9ec8a Update CHANGELOG and bump version
    • cd23e3f [Fix] no-unknown-property: add align on all the tags that support it
    • 8e07874 [Fix] no-unknown-property: add viewBox for pattern, symbol, view
    • fd90b0e [Fix] no-unknown-property: allow abbr on \<th> and \<td>
    • 8aa023a [Fix] no-multi-comp: do not detect a function property returning only null ...
    • 1fa0888 [Fix] no-unknown-property: allow onLoad on \<object>
    • 73350de [Fix] no-unknown-property: add noModule on script
    • 0dc8c9d [Fix] no-unknown-property: add viewBox on marker
    • 2cae464 [Meta] npmignore markdownlint config
    • 22c569b [Tests] no-multi-comp: add passing test
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependency 
    opened by dependabot[bot] 0
  • Update docs

    Update docs

    What is the purpose of this pull request? (put an "X" next to item)

    • [x] Documentation update

    What changes did you make? (Give an overview)

    Sync the latest update of Who uses JavaScript Standard Style? to all languages.

    Which issue (if any) does this pull request address?

    None.

    Is there anything you'd like reviewers to focus on?

    I only copy-pasted the logos part. I didn't translate those two sentences under logos.

    In addition to companies, many community members use standard on packages that are [too numerous](https://raw.githubusercontent.com/standard/standard-packages/master/all.json) to list here.
    
    standard is also the top-starred linter in GitHub's [Clean Code Linter](https://github.com/showcases/clean-code-linters) showcase.
    
    opened by LitoMore 1
  • Please get rid of 2-space indent lint

    Please get rid of 2-space indent lint

    using spaces to indent is a waste of storage and is wearing out space bars around the world. All modern IDEs allow you to set tab-indentation to the size of your liking. There is just no need to carry on using spaces for indentation - and certainly not insist on it.

    opened by reinpetersen-serenaandlily 5
Releases(v17.0.0)
  • v17.0.0(Apr 20, 2022)

    We're super excited to announce standard 17!

    This major release fully focuses on getting in sync with the wider ESLint ecosystem and doesn't in itself introduce any new rules or features.

    When you upgrade, consider running standard --fix to automatically format your code to match the current set of rules.

    This is the first release by two of our standard co-maintainers @Divlo and @voxpelli. Buy them a cake if you run into them, thanks for getting this release out!

    Major changes

    • eslint-config-node has been replaced with the up to date fork eslint-config-n. If you have used comments like // eslint-disable-line node/no-deprecated-api you now have to reference the n/ rules instead.
    • object-shorthand rule (as warning)
    • Use of ESLint 8, which allows for support for all of the latest syntax that ESLint 8 includes, such as top level await #1548 #1775
    • --verbose by default

    Changed features

    • Update eslint from ~7.18.0 to ^8.13.0
    • Update eslint-config-standard from 16.0.3 to 17.0.0 to adapt to ESLint 8
    • Update eslint-config-standard-jsx from 10.0.0 to ^11.0.0 to adapt to ESLint 8
    • Update standard-engine from ^14 to ^15.0.0 to adapt to ESLint 8, see its CHANGELOG
    • Move from [email protected]~11.1.0 to [email protected]^15.1.0 to adapt to ESLint 8
    • Update eslint-plugin-import from ~2.24.2 to ^2.26.0
    • Update eslint-plugin-promise from ~5.1.0 to ^6.0.0
    • Update eslint-plugin-react from ~7.25.1 to ^7.28.0

    https://github.com/standard/standard/compare/v16.0.4...v17.0.0

    Source code(tar.gz)
    Source code(zip)
  • v17.0.0-2(Feb 3, 2022)

  • v17.0.0-1(Jan 31, 2022)

    • Fix: Ensure we support all of the latest syntax that ESLint 8 includes, such as top level await #1548, fixed in https://github.com/standard/eslint-config-standard/pull/212

    https://github.com/standard/standard/compare/v17.0.0-0...v17.0.0-1

    Source code(tar.gz)
    Source code(zip)
  • v17.0.0-0(Jan 31, 2022)

    We're finally able to offer a pre-release of ESLint 8 based standard 17!

    This major release fully focuses on getting in sync with the wider ESLint ecosystem and doesn't in itself introduce any new rules or features.

    This pre-release exists to test out the ESLint 8 related changes and discover possible backwards incompatible changes that comes with it and mitigate unintended such before a stable release.

    When you upgrade, consider running standard --fix to automatically format your code to match the current set of rules.

    Changed features

    • Update eslint from ~7.18.0 to ^8.8.0 #1725
    • Update eslint-config-standard from 16.0.3 to 17.0.0-0 to adapt to ESLint 8 #1725
    • Update eslint-config-standard-jsx from 10.0.0 to 11.0.0-0 to adapt to ESLint 8 #1725
    • Update standard-engine from ^14 to ^15.0.0-0 to adapt to ESLint 8, see its CHANGELOG #1754

    https://github.com/standard/standard/compare/v16.0.3...v17.0.0-0

    Source code(tar.gz)
    Source code(zip)
Owner
Standard JS
🌟🌟🌟 JavaScript Style Guide, with linter & automatic code fixer
Standard JS
Isolated React component development environment with a living style guide

Isolated React component development environment with a living style guide React Styleguidist is a component development environment with hot reloaded

Styleguidist 10.5k Sep 30, 2022
Isolated React component development environment with a living style guide

Isolated React component development environment with a living style guide React Styleguidist is a component development environment with hot reloaded

Vladimir Bezrukov 1 Oct 28, 2021
React 17's automatic JSX runtime for your entire bundle

vite-react-jsx React 17's automatic JSX runtime for your entire bundle Features Replaces React.createElement calls in your entire bundle (even for pre

all oc 122 Aug 31, 2022
The recommended Code Splitting library for React ✂️✨

React code splitting made easy. Reduce your bundle size without stress ✂️ ✨ . npm install @loadable/component Docs See the documentation at loadable-c

Greg Bergé 6.8k Sep 30, 2022
Sapling - A convenient way to traverse your React app in VS Code

Sapling - A convenient way to traverse your React app in VS Code

OSLabs Beta 461 Sep 8, 2022
Let's learn React by building react within 100 lines of code

kReact Let's learn React by building react within 100 lines of code ???? Medium article: https://kamesh-dev.medium.com/kreact-building-your-own-react-

kamesh sethupathi 6 Aug 11, 2022
CodeSwing is an interactive coding playground for VS Code

?? CodeSwing is an interactive coding playground for VS Code, that allows you to build/explore/learn rich web applications ("swings"). It's

Jonathan Carter 908 Sep 24, 2022
Use SWC with Rollup to transform ESNext and TypeScript code.

rollup-plugin-swc SWC is an extensible Rust-based platform for the next generation of fast developer tools. This plugin is designed to replace rollup-

Sukka 59 Sep 9, 2022
A Web library to simply integrate Agora Video Calling or Live Video Streaming to your website with just a few lines of code

Agora React Web UIKit Instantly integrate Agora video calling or streaming into your web application using a React based UIKit for the Agora Web SDK.

Agora.io Community 23 Sep 9, 2022
Code Kitchen - a React live-coding playground

Code Kitchen is a React live-coding playground which allows the developers to embed React component demos into a React UI library’s web documents.

FreeWheel, a Comcast Company 64 Aug 27, 2022
React Dev Inspector - jump to local IDE code directly from browser React component by just a simple click

React Dev Inspector Introduction This package allows users to jump to local IDE code directly from browser React component by just a simple click, whi

zthxxx 811 Sep 25, 2022
Embed code samples from different frameworks with a live preview inside your existing Docusaurus pages.

docusaurus-plugin-code-preview Embed code samples from different frameworks with a live preview inside your existing Docusaurus pages. Quick Installat

Sean Perkins 3 May 28, 2022
🦋 Jump to local IDE source code while click the element of browser automatically

?? Why When developing a React app, you have a lot of components in your app. Sometimes you may forget where the code is located that you want to edit

Frozen FIsh 99 Sep 20, 2022
Easily detect React components source code from Chrome!

Easily detect React components source code from Chrome!

Kyohei Fukuda 115 Sep 28, 2022
Delightful JavaScript Testing.

?? Delightful JavaScript Testing ????‍?? Developer Ready: A comprehensive JavaScript testing solution. Works out of the box for most JavaScript projec

Facebook 40.3k Sep 27, 2022
JavaScript Testing utilities for React

Enzyme Enzyme is a JavaScript Testing utility for React that makes it easier to test your React Components' output. You can also manipulate, traverse,

enzyme - JavaScript Testing utilities for React 19.9k Oct 1, 2022
Human resource management system with react javascript

HRMS (Human Resource Management System) UML Component Diagram Getting Started with Create React App This project was bootstrapped with Create React Ap

Barış Tan 6 Sep 18, 2022
A comprehensive Eslint configuation package for JavaScript & TypeScript projects, with support for React.

AngaBlue Eslint Config ????‍?? A comprehensive Eslint configuation package for JavaScript & TypeScript projects, with support for React. ?? Homepage I

null 1 May 30, 2022
Foxpage SDK for JavaScript in the browser and Node.js.

Foxpage SDK JS Foxpage SDK for JavaScript in the browser and Node.js. ✨ Project <Project Root> ├── .storybook // storybook config

Foxpage 4 Dec 16, 2021