Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
- #2815077: Adopt airbnb javascript style guide v14.1 as new baseline javascript coding standards for Drupal 8 core and contrib is mostly approved. It's within step 7 of https://www.drupal.org/project/coding_standards, already having been tagged "Core committer approved", but awaiting some implementation details and discussion before being moved back to the coding standards queue for official closure and coding standards documentation updates.
- It's likely that some overrides will be desired and approved as well. For example, the patch in #2815077-63: Adopt airbnb javascript style guide v14.1 as new baseline javascript coding standards for Drupal 8 core and contrib includes a few.
- Per #2815077-57: Adopt airbnb javascript style guide v14.1 as new baseline javascript coding standards for Drupal 8 core and contrib, most projects listed in https://github.com/airbnb/javascript#in-the-wild maintain their customizations as a github fork. Some, such as https://github.com/DoSomething/eslint-config, also provide a shared ESLint config.
- In this issue, let's decide if we want to: maintain a git fork of https://github.com/airbnb/javascript and/or provide a shared ESLint config package so that Drupal's ES6 styleguide can be simply referenced in
.eslintrc.json
asextends": "@drupal/eslint-config"
or similar. Or if not that, then what in lieu of that?
Proposed resolution
Separate the rules for drupal estlint config in it's own drupal project.
- Create a d.o project with the eslint/prettier configuration
- publish an up to date
eslint-config-drupal
npm package - require drupal config from package.json
Remaining tasks
- Identify pros/cons of maintaining a git fork of https://github.com/airbnb/javascript.
- Identify pros/cons of providing and maintaining a shared, drupal-namespaced, ESLint config package.
Comments
Comment #2
effulgentsia CreditAttribution: effulgentsia at Acquia commentedComment #3
mikemai2awesome CreditAttribution: 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 CreditAttribution: droplet commented@mikemai2awesome,
core/.eslintrc.json
is your answer.nowadays, we need not remember the style guide. Just run prettier to get the result.
Comment #5
mikemai2awesome CreditAttribution: 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 CreditAttribution: 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.json
config 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-drupal
back 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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)