Nest: [Discussion] Prettier as standard in NestJS project

[theArianit]

Why is prettier as standard devDependencie installed with nestJs projects? I don't like to use prettier personally, I prefer eslint and I configured it perfectly to my style and liking. So, is there any way around it, to not install it with the nestjs project? can't there be an option during project creation that will ask you if you want to use it or not?

[jmcdo29]

The way I see it, ESLint should enforce rules about how code should be written as to what are best practices (no-return-await, no-unused-varaibles). Things that end up being code smells and can lead to problems if you aren't expecting them.

Prettier, on the other hand, is a code formatter, to help enforce the same code style across all files.

While you can configure ESLint to be a formatter as well, I see the two as having separate jobs and purposes, so I'm for keeping things the way that they are. Prettier can also work on files that ESLint doesn't support (md, yml, html) to make sure that __everything__ follows the same standards, which gives it a plus in my book.

[theArianit]

Ok, I know the purpose of prettier and that eslint is not a replace for it. But not everyone likes to work the same way, and options should be offered instead of forced.
Prettier can not be configured therefore it messes up the code for me, I don't like the rules it has. eslint offers just the right thing that I want and need and you can configure everything to your taste.
Anyway, formaters and linters should be an option to choose when creating a project.
Creating a vuejs project gives you a lot of options on this part. why not do the same when we are all about choices and preferences?

[jmcdo29]

options should be offered instead of forced

I'm not sure what would be forced here. Prettier is installed by default but you are by no means forced to use it

Prettier can not be configured

I'm not sure what you mean here, but prettier does have configuration options

Any formatres and linters should be an option

Sure, but at the same time not every option should be shown while spinning up a new project. That could lead to some overwhelming of new developers not knowing what all they are installing. Nest is opinionated, and while going with it's opinions on most things makes your life easier (folder structure, class structure, etc), things it installs by default are pretty easy to remove

why not do the same when we are all about choices and preferences

I mean, we could, and add a flag for each individual addition we want, so now we have the following to set up a pnpm based nest project

$ nest new my-project --prettier --eslint --skip-install

and to not trigger any other the options popping up and prompting us for a selection (I'm a fan of not having prompts pop up), but man is that a long command with a lot of flags to remember.

As developers we definitely have choices and freedom for what to use. A great example is that by default, Angular uses karma, jasmine, and protractor for testing. These are all fine libraries, but I prefer to use jest and cypress, so it's up to me to take Angular's opinion into account, remove their defaults, and use what I prefer. (Also swapping TSLint to ESLint)

I'm not sure how much useful adding the option to the new script would be, but I'd be happy to hear other's thoughts on it as well.

[theArianit]

I know a lot of developers beside me who have issues with prettier. you can configure few things, but don't have full control over it, not like you have with eslint. I personally just like 3 formatting rules: spaces before and after operands, ; at the end and line breaks. but sometimes I want to not follow all rules, for different cases I want different formatting, and I am used to format the code myself most of the times, to make it readable for me for the future when I come back. and eslint alone gives me everything I need and I can set it up to auto format it, warning me or throw errors. but whatever.
A project, in my opinion should not offer any formatting without the user to agree first. it is anyway easier to install prettier and eslint than to uninstall them, delete the files and remove all references.

I tried your command but it says that --prettier is unknown.

[jmcdo29]

The --prettier command flag was an idea of what it _could_ look like. That doesn't exist yet.

A project, in my opinion should not offer any formatting without the user to agree first. it is anyway easier to install prettier and eslint than to uninstall them, delete the files and remove all references.

Maybe, so. I'd love to hear other's thoughts on this. Nest has it's opinions so that's how default projects are set up.

[smolinari]

I don't see an issue with Prettier being installed as a formatter along with ESLint being a linter. As long as the two aren't set up to do the same things, they then have their own clear purpose. Code formatting and code linting.

In fact, I too know of the issue devs have with Prettier and it's usually the issue of how to use it successfully within VSCode along with ESLint. The fact Prettier is set up properly means Prettier in VSCode also works properly automatically. Win-win if you ask me.

Prettier is also very simple to remove.

yarn remove prettier

rm .prettierrc

Done.

Scott

[theArianit]

removing prettier is a bit more than just that. you have to remove eslint-config-prettier also and delete the references in .eslintrc and in the packages you also have to remove one or two lines.
most of people who use prettier re-use their configurations or make them globally.
but I see that we can agree that some, few or a lot of devs don't like prettier. and one choice to add it or not, like which package manager to use, should be added.

[smolinari]

You are right. eslint-config-prettier needs to be removed too and the settings in eslintrc. That's just two steps more.

And please don't misrepresent what I said. I said usually the issue with devs (that I know of) is getting Prettier to work properly with ESLint and VSCode. The fact it is set up "correctly" and Prettier and ESLint work in Nest means I am saying the Prettier setup being there helps devs with the issues I know about. With your suggestion to opt out of Prettier in the new command, if devs then decide to add Prettier back into their setup, then they'll end up with the problems I'm referring to.

I'm for the Prettier being setup up automatically. Maybe the solution is to add the 4 steps in the docs on how to remove Prettier?

Scott

[kamilmysliwiec]

We don't plan to remove prettier from the starter boilerplate code. Feel free to not use it though. As @smolinari pointed out above, removing prettier from your repo shouldn't take longer than 2 minutes.