Summary:
Provides some really nice helpers and generators for
multi command CLIs, including test helpers and all
sorts of output niceties. This should make it quite
easy for us to add additional sub-commands for
bundling, publishing and keeping docs for all of it.
Heroku maintains this and provides some excellent
docs, too: https://oclif.io/
My only complaint is that it's class-based but that's
effectively only the way to declare new commands and
enforces a set of required/static properties on it.
Reviewed By: nikoant
Differential Revision: D19970293
fbshipit-source-id: 4228e502198c6fd376854a90ed2f01da29e96bc2
Summary: This is required to properly run eslint in Atom/VSCode on TypeScript files
Reviewed By: jknoxville
Differential Revision: D16201418
fbshipit-source-id: 31da04c2d313e9147e0f868c1af15bf3115e6d6a
Summary: It's annoying to have to treat things like they might not be errors, inside catch blocks. This should stop that.
Reviewed By: passy
Differential Revision: D16201509
fbshipit-source-id: b028ea3a1e0766763fcf2659d80456f4dd281c40
Summary: Taking another stab at adding some lint rules to make it harder to shoot yourself in the foot. Hopefully nothing too controversial. Preferring spread and rest should lead is more readable and there's no downside when using ES6. The "useless" rules are just things like renaming imports to the original name which should only happen during refactors.
Reviewed By: jknoxville
Differential Revision: D16180453
fbshipit-source-id: 1cf6851b7726c0aee953ec7cf7dd6fa0aca32253
Summary:
Non-final identifiers make code harder to understand.
This is particularly true for JavaScript where even the *type*
can change as a value gets reassigned later.
This enforces to use `const` whereever possible, but doesn't
"outlaw" `let`. Mixed destructuring is also still allowed.
Used `eslint --fix` to change all existing cases.
Reviewed By: jknoxville
Differential Revision: D16131329
fbshipit-source-id: 2eceaca7c603b71b36e005be5d135e1849f2518d
Summary: This will make it easier to handle errors, because you know you can get the message out, along with stack trace, without having to deal with potentially any object that could be passed in.
Reviewed By: passy
Differential Revision: D16006180
fbshipit-source-id: f200965d7663c5f8a471603fceb6b4cdbea73381
Summary:
There's been an ongoing fight between eslint and prettier.
You win, prettier.
Reviewed By: danielbuechele
Differential Revision: D14799153
fbshipit-source-id: a4f0546a3a468bb21fed47d61bc14bd7e6f0b185
Summary:
I must have run this locally on an outdated version of eslint or the
plugin, because I did not see all the formatting errors. This is because
`eslint-plugin-prettier` dropped support for the `fb` preset (see https://github.com/prettier/eslint-plugin-prettier/pull/113/files). This restores the equivalent ruleset explicitly.
Pull Request resolved: https://github.com/facebook/flipper/pull/363
Reviewed By: danielbuechele
Differential Revision: D13839021
Pulled By: passy
fbshipit-source-id: 59e27a241e8aada8648b175ab8abbdfbd391556e
Summary:
Wanted to do that for a while, but the previous eslint error
blocked me. Continues running with the same level or warnings.
Reviewed By: jknoxville
Differential Revision: D13818478
fbshipit-source-id: ac12888dd4177316020c947925d4ff9d64784140
Summary: Adds support for optional chaining to the codebase, enables flow and eslint support for it.
Reviewed By: passy
Differential Revision: D9940732
fbshipit-source-id: 730aa76653bd22a8fa17a73e72b3a7329de0226c
