linter-flow icon indicating copy to clipboard operation
linter-flow copied to clipboard

Errors/warnings only detected for files that are in an unsaved state

Open cameronhimself opened this issue 9 years ago • 10 comments

Steps to reproduce (for me, anyway):

  1. Open a saved file that is known to contain flow errors. Linter displays no errors.
  2. Start typing anything. Linter immediately starts displaying all errors.
  3. Either undo or manually bring the file back to its saved state and the linter errors disappear again.
  4. Start typing again so that the errors once again show up.
  5. Save the file. Errors immediately disappear.

Atom, my flow binary, and this plugin are all up to date (1.6.0, 0.22.1, and 5.0.0 respectively). Mac OS X 10.9.5.

cameronhimself avatar Mar 22 '16 06:03 cameronhimself

I just tried it and I could not reproduce the error. My best bet is that you've run into the same issue where the linter has problems detecting the flow comment correctly.

The other possibility: Currently linter-flow uses flow check-contents to check for unsaved files, and thus gets changes for the currently open file. When the current file is saved, it uses flow status to get all the errors in the project.

It's possible that flow status is just taking too long and all you're seeing is a delay.

nmn avatar Mar 22 '16 08:03 nmn

So it turns out that this is the behavior I see for a file that does not have the // @flow comment at the top. When I add the comment, everything works as expected.

So I guess this issue report is now about how flow is enabled for unsaved files even when the comment tag is not present. My .flowconfig file is empty (no changes made to it after flow init).

cameronhimself avatar Mar 22 '16 17:03 cameronhimself

This was regression in v5.0.0 where the detection for the @flow comment was broken.

// @flow is ignored /* @flow */ is accepted.

If there is no inline comment in the file, it would incorrectly assume the comment exists.

Fixed in #80

nmn avatar Mar 22 '16 19:03 nmn

Should be fixed in 5.1.0

nmn avatar Mar 27 '16 21:03 nmn

My colleagues and I are still seeing the behaviour seen in the original issue, with the same steps to reproduce. I tried changing the flow comment, however, none seems to work as expected. I am on 5.1.0, atom 1.7.2 osx 10.11.1, with linter 1.11.4 here is a file that displays this behaviour:

// @flow

const foo: number = '';

anthillape avatar Apr 30 '16 10:04 anthillape

@cameronhimself or @anthillape are either of you still experiencing this issue with v5.5.0?

Arcanemagus avatar Aug 09 '16 21:08 Arcanemagus

I'm experiencing the bug as of right now, with version 5.5.0. I get hints both as tooltip and in the bottom area in an unsaved file, but they are gone as soon as I save the file.

This issue occurs whether or not I have linter-eslint enabled, which also reports to the same areas.

I tried it with both /* @flow */ and // @flow

I'm running Atom 1.13.0, flow-bin 0.37.4 and linter-flow 5.5.0

emiljohnsen avatar Jan 18 '17 10:01 emiljohnsen

This bug is probably a bug with flow itself. Longer-flow uses flow status for saved files. But it uses a different command for unsaved files. That could be causing the problem. Nuclide fixes this problem by only showing you errors after you save the file. Would you prefer that?

nmn avatar Jan 18 '17 16:01 nmn

I'd prefer linter-flow to behave like linter-eslint, and I'd prefer to use linter-flow instead of dealing with a second "type" of plugin, hah.

I haven't checked out nuclide, or any other particular flow linters.

Eslint, IIRC, evaluates the files on save and displays errors afterwards, which I'd prefer.

emiljohnsen avatar Jan 18 '17 17:01 emiljohnsen

@emiljohnsen eslint works on the fly too. There's an option though. I'll try and make it work with that option.

nmn avatar Feb 21 '17 18:02 nmn