Create eslint and prettier separate in server

[jzunigarce]

I suggest creating a configuration file for eslint and another for prettier for the server, we could move the one in the root to the front and so each one has its own configuration.

[gbowne1]

thats a great idea. However, Do we really need prettier and eslint on the server? The rc files in the root take care of both. Was your idea to have configs for both client and server?

This being said, I no longer use eslint. It became a configuration nightmare if you use prettier and eslint together in a React project that has a configuration outside of the CRA scope.

I am using quick-lint-js https://quick-lint-js.com/ && https://github.com/quick-lint/quick-lint-js && https://marketplace.visualstudio.com/items?itemName=quick-lint.quick-lint-js which although it has a configuration file, it is totally not necessary and does not need plugins for JSX, etc. and support for Typescript is coming.

[jzunigarce]

We would have a custom configuration for each one. Also, in my case that I don't use VSC, it forces me to install the dependencies for it to work correctly, if I configure it on the server, I can install them with npm

[gbowne1]

that is some of the things that I don't like about ESLint, although it works fine, the configuration is a pain in the.. Prettier is fine.

I wonder if that is an artifact or biproduct of not having eslint and prettier installed to either one, because we do not have prettier or eslint installed to either one at the moment. If you have ESLint and Prettier installed and/or one of the extensions installed in your editor (if any exist) it would be using whatever you're using locally.. just grabbing the global config in the root.. unless you have a .eslintrc and/or .prettierrc in your local (outside of the project).

Am having this sort of problem in reactsocialnetwork.. the last 20 odd merges were us trying to fix the ESLint/Prettier config. Fix one thing, another thing breaks.

[jzunigarce]

The idea when using them is to establish a code style, at the time you suggested using ES6 modules instead of CommonJS, I consider that if we configure the tool well, it will bring us multiple contributions, also for the installation of the libraries it should not be a problem because we can install them as dev-dependencies with node

[gbowne1]

yeah, I only suggested ES6 as a way towards ES7 and newer code style rather than work backwards. At this point we should be using at least ES2015 ~ ES2020 but we will get there.

Yeah, I agree about devDepenencies as well as having a good configuration.

Using ES7 or any thing newer would require using some of @babel/core @babel/node @babel/preset-env

[gbowne1]

I for sure would like to be able to use import when importing modules insteaad of var, const, etc.