Skip to content
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

Ban the flow any type. #478

Closed
harrysarson opened this issue Dec 12, 2020 · 3 comments · Fixed by #475
Closed

Ban the flow any type. #478

harrysarson opened this issue Dec 12, 2020 · 3 comments · Fixed by #475

Comments

@harrysarson
Copy link
Collaborator

There’s eslint-plugin-flowtype/no-weak-types.

  1. I could install that plugin.
  2. Enable the rule in our flow config.
  3. Confirm it works by changing a type alias to any somewhere and checking that CI fails.

Thanks for the suggestion for this issue @lydell :)

@lydell
Copy link
Collaborator

lydell commented Dec 12, 2020

Enable the rule in our flow config.

Just to clarify, we would enable it in .eslintrc.json (not .flowconfig).

In .flowconfig we actually have unclear-type=off. An alternative would be to enable that instead. I suspect that’s harder since the ESLint rule only warns about explicit any annotations, while the Flow rule warns about inferred any types as well.

@lydell
Copy link
Collaborator

lydell commented Dec 12, 2020

Turns out the code base has cleaned up a lot since last time I touched .flowconfig – enabling unclear-type only caused 2 errors that were easy to fix so I went ahead and did that: 43b76cc (#475)

@lydell lydell mentioned this issue Dec 12, 2020
@harrysarson
Copy link
Collaborator Author

Wow, nice work

harrysarson pushed a commit that referenced this issue Dec 17, 2020
This makes the watcher faster and more stable! As a bonus, this made the code much more organized.

- Concentrate all `process.exit` in elm-test.js (except one in Install.js where I found no clean solution). Besides making the code easier to follow, it allows the watcher to continue running (and recover) even if there are errors.

- Don’t crash/stop running tests if files are removed.

- Pick up new Elm files added.

- Fixes #225

  We already had code for waiting for the previous run to finish before starting the next run, but it queued up every single file change/add/remove event and ran that many runs one after the other. Now, for all watch events during a run we run _once_ after the current run for all of them. We also sleep 100 ms at the start of each run to catch more events happening close by (such as when adding/removing a whole folder of tests). (Note: We used to sleep at least 500 ms via the [awaitWriteFinish](https://github.com/paulmillr/chokidar#performance) chokidar option.)

  I’ve also tested manually that running elm-format on save doesn’t cause double test runs: #194

- Fixes #355

  We now find the closest elm.json upwards in the folder hierarchy.

- Resolves #453 (comment)

  The watcher now listens for changes to elm.json and properly recalculates things. I thought that I would have to recalculate some things only when elm.json changes for performance, but after making the globbing faster there was no need so we simply rebuild everything on each run.

- Closes #463 and closes #464

  I can’t find any more places to use async/await.

- elm.json is now decoded properly in one place rather than here and there and just being `any`. We now have 0 explicit `any` type annotations!

- elm-test.js now only contains CLI logic and subcommand dispatching. The code for running tests have been moved to RunTests.js and to FindTests.js (which used to be called Runner.js).

- Improved .flowconfig that is stricter. Closes #478

- And lots of little code improvements along the way! I only touched things that I needed to change anyway in order to not make the diff balloon too much.

I’ve done some manual testing on Windows, Mac and Linux to make sure things work like they should.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants