#flowtype

/

      • chenghiz has quit
      • Unhammer has quit
      • Unhammer joined the channel
      • leebyron has quit
      • leebyron joined the channel
      • charliesome has quit
      • charliesome joined the channel
      • phpnode has quit
      • leebyron has quit
      • charliesome has quit
      • charliesome joined the channel
      • phpnode joined the channel
      • phpnode has quit
      • Deide joined the channel
      • charliesome has quit
      • enkristoffer has quit
      • charliesome joined the channel
      • charliesome has quit
      • charliesome joined the channel
      • charliesome has quit
      • alexx joined the channel
      • alexx has quit
      • alexx joined the channel
      • charliesome joined the channel
      • Bnaya joined the channel
      • coot joined the channel
      • coot has quit
      • alexx has quit
      • alexx joined the channel
      • alex__ joined the channel
      • alexx has quit
      • coot joined the channel
      • gajus
        Does Flowtype not support `export type {TypeName}` syntax?
      • phpnode joined the channel
      • phpnode has quit
      • phpnode joined the channel
      • Unhammer has quit
      • phpnode_ joined the channel
      • Unhammer joined the channel
      • phpnode has quit
      • phpnode_ has quit
      • phpnode joined the channel
      • phpnode has quit
      • phpnode joined the channel
      • theonefoo joined the channel
      • theonefoo
        If I have a function that expects a required argument and returns a promise depending on that argument, I would usually add something like if (!argument) { return Promise.reject(new Error(‘argument is required’)); }. But when I add flow checking and change myFunc(arg) to myFunc(arg: string), when I want to test for the case where the argument is missing by invoking myFunc() or myFunc(undefined) in the test, flow complai
      • that its expecting a string.
      • Should I remove the check if I am using flow in this case?
      • If so, when someone would use that function and forgets to add // @flow to the file that uses myFunc, would they be notified of the required argument? I’d much rather reject with an error.
      • flow-help: :)
      • bradleymeck joined the channel
      • phpnode has quit
      • theonefoo has quit
      • theonefoo joined the channel
      • charliesome has quit
      • charliesome joined the channel
      • coot has quit
      • bradleymeck has quit
      • phpnode joined the channel
      • charliesome has quit
      • chenghiz joined the channel
      • glevi
        theonefoo: If you're building an npm library, it can make sense to have both the runtime check and the flow annotation
      • So people who use Flow will see the error quickly while they're writing the code
      • But people who don't will still get an error at runtime
      • theonefoo
        glevi: how would you prevent flow from complaining that the argument should be a string when your test passes undefined as the argument?
      • or doesn’t pass an argument at all?
      • glevi
        theonefoo: You could add a suppression comment to the line before the error in the test that says this is an expected error
      • theonefoo
        Right, that’s one way. There is no way to do this without the flow comment?
      • glevi
        theonefoo: Well you could type your function as myFunc(arg?: string) but then you wouldn't get a Flow error when calling myFunc() with no arguments.
      • theonefoo
        I feel someone writing a lib with these runtime checks + using flow, writing these comments everywhere in the tests that check for the missing argument would be rather tedious
      • glevi: yeah, that defeats the purpose of using flow to check for a required argument
      • for the moment I decided to remove the runtime check and use flow to notify the user that the argument is required
      • glevi
        theonefoo: At Facebook we tend to us a $FlowExpectedError suppression in tests. It's kind of like a test assertion that Flow would have complained
      • So that's what I personally recommend.
      • theonefoo
        but then it’s up to the user/dev to configure their editor to notify of flow errors, otherwise it could be caught in CI, when that is already too late
      • glevi: I see
      • glevi
        theonefoo: Right - it's good for it to be caught early, but being caught late is better than never being caught
      • And it's good to test both behaviors :)
      • theonefoo
        fair enough, thanks for the input :)
      • glevi
        theonefoo: np, good luck!
      • Bnaya joined the channel
      • Rodya_ joined the channel
      • theonefoo
        glevi: just out of curiosity, why do you think its good to have both the runtime check and flow?
      • in the case of a required argument for a function
      • glevi
        theonefoo: So if I'm working in a Flow codebase, I only use Flow and I skip the runtime checks
      • Runtime checks are annoying to add, add bytes, and can get expensive to evaluate.
      • theonefoo
        but? :)
      • glevi
        We used to have a runtime checking system before Flow that would only run in development situations, since it was too slow for prod
      • But if I were to publish an npm library and I didn't know that my users were using Flow, I might add some runtime checks
      • As long as they didn't add too much overhead
      • theonefoo
        all right, let’s say we’re working in a codebase that uses flow, but not everywhere, and it is not a library, but a backend application
      • in your opinion, would it make sense to have the runtime checks there?
      • or would you prefer to only use flow for something like this and enforce developers to configure flow notifications for their editors (perhaps after configuring flow to run on CI)
      • glevi
        theonefoo: Yeah, at a certain point we added a lint warning to our codebase to complain when code is not in @flow
      • We set up CI for Flow pretty early and enforced 0 errors in our codebase
      • (Though we add suppression comments sometimes)
      • Almost every function makes assumptions about its arguments. It's definitely too much for every function to have runtime checks
      • But it's not unreasonable for some critical codepath to be careful
      • theonefoo
        thanks again glevi, I’ll keep these things in mind