Problem/Motivation

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

effulgentsia created an issue. See original summary.

effulgentsia’s picture

mikemai2awesome’s picture

Issue tags: -JavaScript +JavaScript

What'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)

droplet’s picture

@mikemai2awesome,

core/.eslintrc.json is your answer.

nowadays, we need not remember the style guide. Just run prettier to get the result.

mikemai2awesome’s picture

@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.

jhodgdon’s picture

The 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.

droplet’s picture

This 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)

nod_’s picture

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.

droplet’s picture

outside Drupal or Drupal Core?

You can maintain it in it d.org and git it. d.org offers public git access (and gzip).

nod_’s picture

Issue summary: View changes

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.

droplet’s picture

Assumed you meant publish to npmjs.com

But you can just do it:

`npm install https://git.drupalcode.org/project/drupal_codestandard.git`

droplet’s picture

If 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)