JS Best Practices about engineering-best-practices HOT 16 CLOSED

There's a couple different tools for doing this sort of linting:

• JSLint
• JSHint
• ESLint
• JSCS

One of my team's clients has us using JSCS, but I'd love to see 10up pick one tool & set of standards for other projects. This would tie into @stevegrunwell 's recent work nicely, too.

from engineering-best-practices.

Based on the WordPress JavaScript Coding Standards JSHint seems to be preferred (core even includes a .jshintrc file).

Personally I've always been partial to JSLint myself, but I think it's because using Crockford's tools always feels like I'm playing on "Hardcore Mode". Anecdotally, JSHint seems to be the most common in WordPress projects (at least those I've seen using a build tool like Grunt).

from engineering-best-practices.

PHP Storm does have both JSHint and JSLint: https://www.jetbrains.com/phpstorm/help/jshint.html as a built in verifier. PHPCodesniffer has been awesome. As I am ramping up my JS sills, I will be adding that to my environment.

from engineering-best-practices.

+1 for JSHint.

from engineering-best-practices.

+1 for JSHint

from engineering-best-practices.

JSHint is more for rudimentary checks. JSCS also does fully-on code-style checks, like enforcing proper whitespace usage. There is a built-in wordpress preset for JSCS: https://github.com/jscs-dev/node-jscs/blob/master/presets/wordpress.json

I use both the JSHint config from Core and also JSCS configured to use the wordpress preset.

from engineering-best-practices.

There is also ESLint which seems to be the most powerful of the tools. However, I think JSHint is enough, and it's what WP core uses so I'm fine with sticking with it for now. +1 JSHint

from engineering-best-practices.

Another vote for JSHint here, but mostly because of Core's use of it.

I really like JSCS, too, but haven't been able to get it to consistently check in all editors/IDEs I use (although command-line usage is okay).

from engineering-best-practices.

Anyone want to write up a PR for JSHint?

from engineering-best-practices.

@tlovett1 I'll be glad to.

from engineering-best-practices.

Great!

from engineering-best-practices.

@tlovett1 I've created a pull request for this: #129

from engineering-best-practices.

I think we should not conform to the WordPress JavaScript Coding Standards. Instead, we should update JavaScript: Code Style & Documentation to reflect the good work done by @allenmoore in #129 and include our own style guide.

While many parts of WP’s standards are widely accepted, there is one rule nigh-seen outside PHP — “Always include extra spaces around elements and arguments” — which includes the following example.

array = [ a, b ];

foo( arg );

foo( 'string', object );

foo( options, object[ property ] );

foo( node, 'property', 2 );

This is very uncommon in JavaScript. Uncommon enough that our documentation’s own JS does not follow it.

I’ve updated #127 to include .jshintrc and .eslintrc error/pattern linting rules and .editorconfig and .jscsrc spacing/style linting rules that reflect the patterns I’ve seen at 10up. These files may then be linked to within our documentation. We can add language to Allen’s changeset that details these two kinds of linters.

Code Correctness

We use tools like [ESLint] and [JSHint] to analyze our code for potential errors or problematic patterns. We use [grunt-contrib-jshint] or [grunt-eslint] to integrate into a project's Grunt configuration, which tests the project's JavaScript files. JSHint's configuration specifications can be included in a special file called .jshintrc, while ESLint’s configuration can be included in a special file called .eslintrc.

Style Uniformity

We use tools like [JSCS] and [EditorConfig] to enforce consistent coding styles in code and documentation. EditorConfig defines coding styles across all text files, while JSCS defines JavaScript-specific coding styles. EditorConfig’s configuration can be included in a special file called .editorconfig, and JSCS’s configuration can be included in a special file called .jscsrc.

JSLint and ESLint are both great tools. ESLint is a newer linter with more rules and clearer rule names than JSHint. Still, it will be useful to have both and use either internally as we form our own cowpath. WordPress does have its own JSHint configuration, but it contains many deprecated rules that escape the scope of JSHint (code correctness vs style uniformity). We’ve been using an EditorConfig configuration in our Yeoman generator for some time with great success.

from engineering-best-practices.

10up has traditionally adhered to WordPress's coding standards, but I agree with Jonathan. I've never liked that whitespace standard. It made more sense before syntax highlighters were widespread. Now...meh.

I'll take a look at #129 and #127 and see if I have anything to add.

from engineering-best-practices.

@daveross makes a valid point. Syntax highlighters makes the need for a whitespace standard pointless. Personally, I write without the whitespace, and allow my editor to format on save based on the WordPress JavaScript coding standards.

from engineering-best-practices.

Stale thread. Just closed the JSLint/ESLint PR. Closing this one.

from engineering-best-practices.