Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Lint codebase using standard #224

Merged
merged 4 commits into from
Aug 18, 2016
Merged

[RFC] Lint codebase using standard #224

merged 4 commits into from
Aug 18, 2016

Conversation

tvararu
Copy link
Contributor

@tvararu tvararu commented Jul 13, 2016

Depends on:

This PR is an open discussion on the topic of using a JavaScript linting tool across our codebases.

I throw my hat in the ring by suggesting standard and demonstrating with this PR how an implementation would work for a node project.

Code was automatically converted using https://github.com/maxogden/standard-format.

We already have govuk-lint whose responsibility it is to handle linting concerns, and I'd love to hear what our thoughts are on relying on that instead.

@@ -6,188 +6,185 @@

// http://www.sitepoint.com/fixing-the-details-element/

(function () {
'use strict';
;(function () {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't need to do this. twbs/bootstrap#3057

@tvararu tvararu force-pushed the linting branch 2 times, most recently from 4f17e50 to 661776a Compare July 13, 2016 14:51
@paulmsmith
Copy link
Contributor

I saw this tweet recently: https://twitter.com/brendaneich/status/741277499376603138 - Tim Berners-lee & Brendan Eich use standard.

@joelanman
Copy link
Contributor

thanks for this, sorry I dont have much experience on this - can you explain a bit more about how it works?

@tvararu
Copy link
Contributor Author

tvararu commented Jul 14, 2016

@joelanman certainly!

1edbe61 is where I've added standard as a project dependency. standard is an opinionated JavaScript linter that uses eslint underneath and acts as a set of sensible defaults for it; here are the most important rules.

Since standard is based on eslint, overriding rules inside a file / ignoring files works through the same mechanisms, and if we want to move away or build on top of its opinionated ruleset, we can easily do so by swapping it with eslint and dropping an .eslintrc file.

Also worth mentioning some other "batteries-included" linters that fork standard or are in a similar vein:

I've hooked it up to npm scripts because I was hoping on travis to run npm test on our behalf on CI, but it looks like it relies on grunt to do it instead. I'll update it.

661776a is the monster commit where I run standard-format on every file, and complete it with a few manual modifications that it's not smart enough to do by itself. Stuff I've had to do is:

  • add path.join() calls where __dirname + '/foo' was being used
  • split var a,\nb,\nc declarations into multiple ones
  • add /* global MyLib */ calls to make it clear that stuff like jQuery or GOVUK is being read from the global context

Hope I didn't waffle too much, I can update the commit/PR messages with more info if any of this is useful to have for posterity.

@joelanman
Copy link
Contributor

thanks! When does the linter run? Or do you have to run it manually?

@tvararu
Copy link
Contributor Author

tvararu commented Jul 14, 2016

@joelanman my hope is to update this so that it runs as part of CI, and combined with text editor plugins that's usually enough for projects I've used it in with other developers. Additionally we could also run the test suite on a pre-push hook, to save a bit of time and get less red ❌'s on pull requests. (I can add that fairly easily if everyone likes the idea)

@tvararu
Copy link
Contributor Author

tvararu commented Jul 15, 2016

TODO:

  • Hook npm test into CI
  • Add documentation about manually running npm run lint or adding editor plugins

@tvararu tvararu force-pushed the linting branch 3 times, most recently from 06a75d8 to 252b8b4 Compare August 9, 2016 16:13
@tvararu
Copy link
Contributor Author

tvararu commented Aug 9, 2016

@joelanman I've written some documentation here: 123082a

This PR is good to go once #223 and #233 are merged.

@NickColley
Copy link
Contributor

@tvararu like the addition in the docs, do you think we could briefly add why we're now linting and why standard being so opinionated is a good thing?

@tvararu
Copy link
Contributor Author

tvararu commented Aug 10, 2016

@NickColley I've updated the latest commit, added two more blurbs on "Why lint?" and "Why standard?" 👌

@tvararu tvararu changed the title [Do not merge] [RFC] Lint codebase using standard [RFC] Lint codebase using standard Aug 10, 2016
@robinwhittleton
Copy link
Contributor

Spoke about this in #frontend. The specific problem this solves is standardising the JS that goes into govuk_prototype_kit, it’s not necessarily being suggested for actual prototypes (although of course people using the kit are free to adopt for their own code if they wish).

@dsingleton
Copy link

Hugely pro some kind of standardised linting across our projects. 👍

As discussed in the FE meeting, standard seems like it might be a good default. Happy to try it for a while on this repo, see how it feels, and roll it out to more repos if it works for us.

@tvararu
Copy link
Contributor Author

tvararu commented Aug 18, 2016

Thanks for the support @dsingleton!

I recall @edwardhorsford mentioning that he'd prefer not to link to the Linting doc from the main page of the README, because it's too technical. There are also a few other things I recall:

  • Update README, remove link to "Linting", link from the CONTRIBUTING file instead
  • Update Linting.md, expand on "Why standard" section (I don't remember exactly what though, @dsingleton to provide guidance)
  • Update Linting.md, provide clear instructions for how to add linting to two popular editors (Sublime Text and Atom) and add a link to the official docs for other editors

Anybody subscribed to this thread feel free to edit this comment with things I've forgotten.

@gemmaleigh
Copy link
Contributor

gemmaleigh commented Aug 18, 2016

If you'd like another project to try this out on, you are more than welcome to do the same for GOV.UK elements!

Aside from the JS from the govuk_frontend_toolkit, some of the govuk_prototype_kit JS has been directly copied from govuk_elements.

If we have JS that can be of benefit to more than one project, it makes sense to move it to govuk_frontend_toolkit.

An example of this is the show/hide js, which will replace what is exists in application.js.

(This is just a FYI, it won't affect this PR - but will mean we can simplify application.js in the future!)

@dsingleton
Copy link

Update Linting.md, expand on "Why standard" section (I don't remember exactly what though, @dsingleton to provide guidance)

My train of thought around this was: Linting rules can be a contentious subject, and a personal preference. We should document why we chose a particular set of rules over others - why standard was a good fit for us (rather than why it's good in general). If we make sure people can understand the reasons behind that choice we're less likely to have rehash discussions over the choice.

Hopefully that helps?

@joelanman
Copy link
Contributor

Happy to merge this if others are?

@tvararu
Copy link
Contributor Author

tvararu commented Aug 18, 2016

@joelanman yes please! ✨

@joelanman
Copy link
Contributor

@tvararu can you rebase against master and I'll merge

Theodor Vararu added 2 commits August 18, 2016 14:19
@joelanman
Copy link
Contributor

thanks everyone! 💃

@joelanman joelanman deleted the linting branch August 18, 2016 13:24
robinwhittleton pushed a commit that referenced this pull request Oct 13, 2016
Breaking changes:

- #244 Migrate documentation into a seperate application

All changes:

- Bump all GOV.UK assets to their latest versions
- Remove duplicate GOV.UK assets copied to the app
- #241 Warn against using the prototype kit to build production services
- #268 Automatically keep the latest release branch up to date. This can be used to update the kit
- #270 Add a new stylesheet for the unbranded layout to fix font issues
- #257 Make CSS output easier to debug (with sourcemaps)
- #237 Make links with role="button" behave like buttons
- #224 Lint the prototype kit’s codebase using Standard. This only applies to the kit’s codebase - there’s no requirement for your app to meet this
robinwhittleton pushed a commit that referenced this pull request Oct 13, 2016
Breaking changes:

- #244 Migrate documentation into a separate application

All changes:

- Bump all GOV.UK assets to their latest versions
- Remove duplicate GOV.UK assets copied to the app
- #241 Warn against using the prototype kit to build production services
- #268 Automatically keep the latest release branch up to date. This can be used to update the kit
- #270 Add a new stylesheet for the unbranded layout to fix font issues
- #257 Make CSS output easier to debug (with sourcemaps)
- #237 Make links with role="button" behave like buttons
- #224 Lint the prototype kit’s codebase using Standard. This only applies to the kit’s codebase - there’s no requirement for your app to meet this
@robinwhittleton robinwhittleton mentioned this pull request Oct 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants