-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add Prettier and ESLint standard configs #5
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @msanroman thanks for kick starting this work.
Regarding prettier, Core is only using it integrated with eslint via this plugin and config and not run independently for the following reasons:
- eslint has two broad categories of rules: format and code check, while prettier only cares about format (and it's quite opinionated about it)
- when working together it's possible to have rules conflicting, so eslint has a set of configs that help you disable the formatting rules from eslint and a plugin that allows you to check and fix formatting rules via prettier-eslint integration (basically eslint runs prettier under the hook).
If the next step in standardization is to have a common eslint setup, I'd find more value on bundling both eslint and prettier configuration in a single shared module.
However, I may be missing some cases where we will have prettier enabled and not eslint. If that's the case then this would be fine. 😄
prettier/README.md
Outdated
> npm install --save-dev @bufferapp/prettier-config | ||
# or | ||
> yarn add -D @bufferapp/prettier-config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If prettier is a peer dependency it would be great to include it in the install command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeeeees! 🙌
Yes! That's a very good one @esclapes . I was prepping an ESLint PR for kicking off the discussion for frontend and backend teams and sharing base settings between them, but maybe we can merge these into this. Right now we have repos that don't have Prettier enabled at all, but the goal is to have both anywhere anyway 😄 |
@esclapes - just added Still, I think with documentation (and if needed, scripting) we could automate the installation of both if needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heya @msanroman thanks for kicking this off!
There is a bunch of options I needed to add for Engage in order to remove some false errors or to make jest
compatible with this configuration. I wonder if we should include this as well in this PR?
eslint/backend.js
Outdated
extends: [ | ||
"./index.js", | ||
"plugin:@typescript-eslint/recommended", | ||
"prettier/@typescript-eslint" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if we should use "plugin:prettier/recommended" as well? We've used it on Engage to displays prettier errors as ESLint errors.
eslint/backend.js
Outdated
plugins: [ | ||
"typescript-eslint", | ||
], | ||
parser: "@typescript-eslint/parser", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to use these option to have the parser working correctly. Not sure it's still necessary:
"parserOptions": { "ecmaVersion": 2018, "sourceType": "module" },
Hey @msanroman ! 👋 Curious if you've seen my comments on the PR :) No rush at all! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @msanroman @CoxyBoris, as mentioned in #10, I have come up with some base configuration using what is in this repo + what was missing from core/engage that we find really useful.
What I have in my PR may represent and include the addition from Boris and Edu wanted to make to this PR.
Two questions:
-
How do you feel about updating this PR with the files I have in Create a base backend package with all the configuration files #10? I'm happy to own that 😊
-
How does it work when importing eslint config which requires installing packages? Do we simply need to tell engineers to install this package + all dependencies?
Sounds good to me thanks!!
hmm shouldn't all dependencies be already listed in |
Yeah maybe! I have no knowledge about how this works, I will only know once I try it. Maybe declaring the dependencies in this package will be enough 🤔 @msanroman since you already researched that part, do you know? |
They should be declared as both Footnotes |
We can use this shortcut to make sure we install the
The key thing is to make sure only the absolute needed is marked as peer deps :) |
Wow, I didn't know about the |
eac9e1f
to
a6f5f90
Compare
"target": "es6", | ||
"module": "commonjs", | ||
"declaration": true, | ||
"outDir": "./lib", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: change this for built
"typescript-eslint", | ||
], | ||
parser: "@typescript-eslint/parser", | ||
ignorePatterns: ["node_modules/*", "built/*", "lib/*", "build/*"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should standardize our tsconfig outDir folder for all repositories. Right now, we have: lib, build, and built depending on repos. I would go for built 😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
built sounds good to me!
"jest/valid-expect": "error", | ||
"no-underscore-dangle": "off" | ||
} | ||
"env": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: replace with actual eslint package we are creating here
rules: { | ||
"@typescript-eslint/no-unused-vars": "error", | ||
"@typescript-eslint/explicit-function-return-type": "error", | ||
"@typescript-eslint/explicit-module-boundary-types": "error", | ||
"jest/no-disabled-tests": "warn", | ||
"jest/no-focused-tests": "error", | ||
"jest/no-identical-title": "error", | ||
"jest/prefer-to-have-length": "warn", | ||
"jest/valid-expect": "error", | ||
"no-underscore-dangle": "off" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tempted to add these rules to the index.js as they should be applied to both FE and BE :in my opinion.
Listing next steps here @msanroman @CoxyBoris
|
Purpose
Prettier
This is the standard Prettier config file for the projects within the https://github.com/bufferapp GitHub organization.
This was created by taking a look at Account, Publish, Authentication Service, Engage (backend), and Engage (frontend) and aiming for a minimal version that relies on Pretier defaults and uses the most common settings set already by our different teams.
There were repositories setting items with default values, such as
tabWidth : 2
orbracketSpacing: true
.Eslint
This exposes two different ESLint configs: one for React frontends and another for Typescript backends. The aim here is to reduce external dependencies and have a minimal configuration that relies on standards based on the tools themselves rather than external companies (aka: eslint-airbnb).
These configurations omit any default setting for now.
Issues
Closes #1 and #2