Active
Project:
Coding Standards
Component:
Coding Standards
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
28 Dec 2016 at 19:50 UTC
Updated:
23 Jun 2020 at 09:41 UTC
Jump to comment: Most recent
.eslintrc.json as extends": "@drupal/eslint-config" or similar. Or if not that, then what in lieu of that?Separate the rules for drupal estlint config in it's own drupal project.
eslint-config-drupal npm package
Comments
Comment #2
effulgentsia commentedComment #3
mikemai2awesome commentedWhat's the status of this issue?
One of the biggest pain points within our organization is that the front-end devs are strictly following the Airbnb JS standards while the Drupal devs follow what is being documented on this page. This creates a lot of friction when we are doing front-end integration. As you can see on the Drupal standards page, the first thing you read is a yellow warning banner saying "This documentation is out of date." Then in the paragraph that follows, it reads "Drupal uses 'eslint-config-airbnb' as ESLint shareable config. Therefore it's reasonable to use 'Airbnb JavaScript Style Guide' as Drupal JS coding standard.
Will this particular issue address the very confusing documentation page? It’s odd that Drupal says to use the Airbnb style guide but doesn’t acknowledge how it differs from their own standards.
Some examples of things that usually trigger debates are when to use var, let, and const, and how to format if/else. (context: we don’t support IE11
or use a transpiler)Comment #4
droplet commented@mikemai2awesome,
core/.eslintrc.jsonis your answer.nowadays, we need not remember the style guide. Just run prettier to get the result.
Comment #5
mikemai2awesome commented@droplet Thank you. That's good for linting the code. It doesn't address the page being confusing though, which some people are still using it as the source of truth, but I will deliver your message to my team.
Comment #6
jhodgdonThe comments above (which may have been unpublished by someone?? why???) refer to this documentation page:
https://www.drupal.org/docs/develop/standards/javascript/javascript-codi...
If the Drupal project is not using that documentation, if it is not any longer our standard, then the page should be updated as soon as possible, because it is there in the coding standards section, and people are following it.
Comment #7
droplet commentedThis isn't outdated but bad written.
In fact, JS guide is the most up-to-date coding standard in d.org . PHP, CSS ..etc just coding as `feel good` (If committers or maintainers don't like it, then you have to re-write your patch)
Since I contributed some patches to CORE to remove the needs of remembering JS styleguide, you know I'm not a fan of writing a history book. (So, I can't help to update it)
To me, I will only tell 2 things:
- Run `yarn prettier` to format your code
- Run `yarn lint:core-js` to lint your code
Then, you can give hints to read Airbnb’s Style Guide / ESlint or Google it for a fix and understand the background story rather than education or copying things into d.org.
(should not more than 100 words)
Comment #8
nod_Right we need to update the documentation page to essentially say: run eslint with the
.eslintrc.jsonconfig and it'll tell you everything needed to know about code format.But the issue asks how much we want to make the drupal config "exportable". As in having a
estlint-config-drupalback then I had a repo for this: https://github.com/theodoreb/eslint-config-drupal (and the matching npm package) which is very not up to date. But overall I'm not sure why we'd export the config. It's definitely doable, but what is the use? simplify what we have in the core directory? but then we're maintaining coding standards (because eslint+prettier == coding standards) outside Drupal.Comment #9
droplet commentedoutside Drupal or Drupal Core?
You can maintain it in it d.org and git it. d.org offers public git access (and gzip).
Comment #10
nod_Very good point, as usual :) I meant outside drupal core. So yes we could have the code in d.o and still publish the package to npm, and actually we could do that for #2402103: Add once.js to core too, we'll get to keep the history and have that in d.o. I'll ping some folks in slack to get some opinions.
Updated the proposed resolution in the issue summary. Let me know what you think.
Comment #11
droplet commentedAssumed you meant publish to npmjs.com
But you can just do it:
`npm install https://git.drupalcode.org/project/drupal_codestandard.git`
Comment #12
droplet commentedIf that must be in CORE, turn that into a package folder and a simple script to clone that folder from CORE to d.org/project also okay. (zero extra maintenance basically)