Prettify

[calebeby]

• Used es6 stuff where applicable (const, arrow functions, etc.)
• Ran it through pretter
  • IMHO, there was way too much whitespace before
  • 2111 lines => 1462 lines
• standard --fix
• Fixed cases where .throws was used with a promise
  • In chai, .throws needs to have parens
  • .throws is not to be used with a promise
  • .be.rejected was used instead
  • Needed chai-as-promised to do this
• Used () on all chai functions (.true, .false, .ok, etc.)
  • This is cleaner because the way chai uses getters with side effects is pretty hacky
  • Needed dirty-chai to do this
  • Fixes the standard error: Expected an assignment or function call and instead saw an expression

[jescalan]

Damn, this is amazing. Thank you for all the hard work here, very impressive. To be honest, I would be perfectly happy to switch this over to prettier entirely and forget standard. I typically use prettier with the --no-semis and --single-quotes options. Do you think that would be a better direction here?

Regardless, this is definitely getting merged 🙌

[calebeby]

Prettier and eslint are different tools. Prettier is good for formatting your code. Eslint can do a little bit of formatting, but its value comes from pointing out errors with your code. For that reason, I think it is most valuable if both tools are used together. There are several options for integrating them. prettier-eslint runs code through prettier, and then through eslint --fix, and then saves the file. eslint-plugin-prettier shows prettier formatting changes as eslint errors that are fixable. Personally, I prefer prettier-eslint.

I think a good direction to take (and this applies to your other projects too) is to use prettier-eslint as the npm lint script, and have the lint run automatically before testing and committing (through husky)

I'm currently working on a cli which modifies your package.json to essentially do that. I'll send a PR here once I've finished it.

[jescalan]

Hey sorry for the late followup here, very busy at work. So just out of curiosity, what kind of errors are caught by eslint that are not caught by prettier?

It seems like, judging by the readme from the project, the eslint portion is basically just for changing some of the prettier formatting into different formatting. Prettier has pretty good options at this point. Personally, I use the single quotes and no semicolon options for all my projects locally, and it works great. If possible, I would prefer to use less tools rather than more, especially if it just means adhering to more of prettier's conventions, as this just makes the formatting more standard, familiar, and simple to deal with.

If there are any specific cases that you use eslint for, I would love to hear them here though!

[calebeby]

I changed my mind, I think we don't need prettier-eslint. Kent C. Dodds mentioned he doesn't use it himself anymore, for the same reason you mentioned. Like I said, I think prettier is good for fixing your code, so you don't have to deal with it yourself, and eslint is good for catching errors. I think it is best if they are used separately.

Because of prettier, the styling rules of eslint don't really matter, but the bug catching ones do.
Some examples:

• no-unused-vars
• eqeqeq
• no-undef
• no-global-assign
• no-redeclare

For my personal projects, I'm using an eslint configuration based on standard with eslint-config-prettier (disables all style rules that conflict with prettier) and some plugins. However, I'd like standard to be a bit more strict sometimes. What do you think of creating our own eslint configuration for static-dev and reshape?

[jescalan]

Ok, I can get down with that. I think the no unused vars one was probably the one I used most frequently. Are there any other rules you have come across that might help and not overlap at all with prettier in that way? All the ones above I agree with.

[calebeby]

You can look through here. There are quite a lot, just ignore the ones under the Stylistic Issues section.

[calebeby]

OK, I'm gonna start working on this. Do you have any ideas for a name?

[jescalan]

Yeah, I looked through all those ones listed and most look great, other than maybe the no console logs one. That would just be super annoying during development to always be getting linter warnings when you're working on stuff, and I prefer to have linters set up so that they are always running within your text editor. Also not a huge fan of no eval, sometimes you need it hah. no-new has also annoyed me in the past. Also pretty much everything in the node/commonjs section I'm not a fan of, other than maybe no-callback-error.

Maybe we can start with just a list of the rules you want to include and we can take it from there?

[calebeby]

Ok, I'm gonna create a repo and upload what I have in a PR. Then you can go through and we can discuss in the reviews.

[calebeby]

Can you give me a use case for needing to disable no-new?

[calebeby]

OK, can you review this? calebeby/eslint-config-static-dev-core#1 I'm not done adding rules yet, but you can start looking them over while I continue to add more

[jescalan]

Sure, one example i ran into recently was this guy: https://github.com/pawelgrzybek/siema#installation

There are a lot like this though, and I don't see this as an antipattern either. Create a new slider object, and if you need to access the API, save the instance to a variable, but if you don't, leave it as just the new invocation.

[calebeby]

OK, that's fair