Closed eapache closed 1 year ago
+1
Yup, this is super valuable. We should have a solution for this.
Not sure what the proper way to "upvote" this would be. But: +1
Would be great to see this being worked on. Ideally this should be configurable to support different platforms like .windows.js
or .web.js
.
Just recently started converting a React Native project into flow and encountered this.
+1
I just ran into this as well.
Another workaround is to add the following to .flowconfig:
module.file_ext=.ios.js
module.file_ext=.js
module.file_ext=.jsx
module.file_ext=.json
Of course you'll have to edit this if you want to check .android or .web
I think this issue can be closed as module.file_ext
can totally handle this without any modification in flow. And it makes things explicit.
Maybe just more docs (maybe another example in the doc)?
I still see an issue here: how can flow validate all files? I mean flow might want to choose .ios.js first, but this might leads to issue if someone update another ext (ex: .web.js, defined after) and do not respect the API of .ios.js version.
@MoOx Flow will need to run through all three code paths.
I don't think this works now, but it could work like this
flow check --file_ex=.ios.js,.js
flow check --file_ex=.android.js,.js
flow check --file_ex=.web.js,.js
Maybe you could do it now with 3 different .flowconfig
Thanks for the alternative suggestion @DaleJefferson, could you please elaborate on how this works for you? I just get flow: unknown option '--file_ex'
when trying this on the CLI.
@bkrem I think there is just a typo, try --file-ext.
@bkrem
I don't think this works now, but it could work like this
It does not work for me, I was just suggesting that it could work like that.
Ah right just a misunderstanding, I thought you meant the suggestion above yours was deprecated rather than your own being a suggestion :)
The problem using the config is that flow will stop on the first file it will find. So if you .ios.js is the first, flow won't check other implementations. That's why trying to do that for each extensions might be a good idea.
module.file_ext=.ios.js
works
but module.file_ext=.android.js
doesn't. Anyone else experiencing this?
@mhollweck the problem is that flow will stop for the first file it will find. It won't resolve and try multiple files. So you might need to use flow with multiples config or try using a CLI options to run flow 2 times... (or maybe use ios by default and run 1 additional time with .android.js)...
@MoOx I know that flow only checks the first file it will find but even if I ONLY check android files it won't recognise my android.js files! Am I the only person with this issue?
@mhollweck : React Native's default .flowconfig is set up to ignore all .android.js files. You can work around this by changing -.*/*[.]android.js
to .*/node_modules/.*/*[.]android.js
in the .flowconfig of your project.
Any progress on this? I currently have this issue with react-native 0.35 and flow-bin 0.32
I spent a bit of time seeing if I could get a quick fork with a fix, but I don't understand ocaml.
Seems to me like someone with more experience could undo the lazy
s in https://github.com/facebook/flow/blob/master/src/services/inference/module_js.ml#L372 to allow the module.file_ext
options order to matter. That way, a native project with
module.file_ext=.native.js
module.file_ext=.js
would resolve any index.native.js.flow
s in a directory before index.js.flow
.
This feature is critical for a pattern I'm using to share web and native code as a single module. Really hoping someone will help soon!
Being able to add filetype/extension specific options should be able to solve this problem.
; Or maybe [options *] ?
[options]
module.global.options=set_here
[options *.js]
module.file_ext=.js
[options *.android.js]
module.file_ext=.android.js
[options *.ios.js]
module.file_ext=.ios.js
[options *.web.js]
module.file_ext=.web.js
Of course, some other variants may work better for configuring the extension type for options, perhaps [options ext.js]
, or [options extesnion=.ext.js]
, maybe [options ext=ext.js]
?
2015? mm ok.
Can anyone please update as to why React Native's .flowconfig is configured in a way to ignore .android.js
files? I cannot find any info on the same. I have also posted it on stack overflow: Why android files are ignored
I would like to know the reasoning as well
If I add module.file_ext=.ios.js
to my flowconfig then I immediately get an extra 100+ flow errors in my project from within React Native 3rd party code in node_modules ...
For React Native 0.46.4+ version name your ios components with a regular name *.js
and Android components with *.android.js
. It should be fine.
@EclipticWld it doesn't seem fine to me. The .flowconfig generated by the React Native CLI still opens as follows:
[ignore]
; We fork some components by platform
.*/*[.]android.js
This will be "fine" only in the sense that Flow will ignore any Android specific files in your project.
@fagerbua I see.
@EclipticWld @fagerbua That is not an issue related to flow, that is more like a react-native issue, in order to make flow run through my app on android I avoid running flow in react-native by ignoring react-native in my .flowconfig
and importing it as mocked library.
I was hoping that module.file_ext
would allow this to sort-of work, but as @kylpo points out in https://github.com/facebook/flow/issues/945#issuecomment-270304437, it seems that the order in which those are given is not respected, which makes interacting between a foo.js
and a foo.ios.js
file impossible.
If my config is:
module.file_ext=.ios.js
module.file_ext=.js
And I have these files:
audio.ios.js
audio.js
Then importing audio
should go to the audio.ios.js
file.
any progress on this?
any progress on this?
any progress on this? (since more than 3 years issue opened and almost year of last comment)
The workaround works for me, but the dependencies usually show up as "unused import"
For a while React Native itself has been getting around this with 2 separate .flowconfig files, which are run as independent checks:
To me this doesn't seem like an unreasonable approach... the way RN forks off platform-specific versions of modules is essentially a way to create different projects per platform, so it's a fair trade-off that they need to be typechecked independently. I generally use the in-code Platform.OS === 'ios'
checks so as not to be going against the JS module system.
Ideally, flow would recognize this pattern, and be able to type-check both implementations against the import (and against each other) to ensure they implement the same interface.
I'm not sure this is really in-line with what RN itself does. From what I see e.g. here: https://github.com/facebook/react-native/issues/22990 it looks like they're now more moving towards Platform.OS
checks in-code, and then <Platform><Component>.js
files. The only times I'm seeing them still using .ios.js/.android.js is when one of those files returns an UnimplementedView, e.g. https://github.com/facebook/react-native/blob/master/Libraries/Components/CheckBox/CheckBox.ios.js , so the interfaces won't match anyway.
cc @TheSavior Do you have any opinion on what could be best approach for Flow here? And with the new native codegen, is RN moving away from .[ios/android].js
files, or are they still going to be a recommended practice?
With react-native, it's theoretically possible to have completely separate sets of JavaScript source-code files for ios and android if you have an index.ios.js and an index.android.js.
https://stackoverflow.com/questions/50272240/does-react-native-perform-tree-shaking is also relevant here.
We now have experimental support for this. https://flow.org/en/docs/react/multiplatform
In recent react-native releases, common practice for files that need platform-specific implementations is to turn
foo.js
into two files:foo.android.js
andfoo.ios.js
. Flow obviously doesn't know what to make of this, which leads to "Required module not found" errors.As a temporary workaround you can add
module.name_mapper
for each such file, but maintaining this list is a lot of work, and the end result is that half your code isn't type-checked at all.Ideally, flow would recognize this pattern, and be able to type-check both implementations against the import (and against each other) to ensure they implement the same interface.