Flow: 0.46
Platform: Windows 10 (git-bash)
TL;DR: Files in a symlinked directory are not found, Flow does not seem to follow symlinks at least on Windows.
Tiny test project: Test.zip
WARNING: The ZIP included the sym-linked directory as full directory! Remove Test/src/system/
and create a symlink with (on Windows) mklink /D system nodejs
inside Test/src/
. If you just unzip it and run Flow there are no errors - obviously.
I use a symbolic link to link to one of my three directories with platform-dependent code (nodejs, browser, react-native). They all have the exact same files and API, just the platform-dependent part of the implementation.
Then I created a symbolic link named system
pointing to the directory with the platform-dependent files. Before that I had ./nodejs/someFile.js
in all require('...')
commands and used a build process to replace the "nodejs" with whatever platform the build was for.
So after switching to this much cleaner method (no code rewrites) Flow gives me a Required module not found
error for each one of the imports that look similar to require('./system/storage-base.js');
(before it was require('./nodejs/storage-base.js');
in the src/
directory and "nodejs" replaced after build in the lib/
directory).
WebStorm has no problem with the symlink (just an aside).
I found #149 but that was closed by the author without giving a reason.
Also: https://github.com/facebook/flow/issues/46#issuecomment-64593695
And also https://github.com/facebook/flow/issues/164 -- this sounds as if it should work when the Flow server is restarted and that only watching for changes is the issue, but I did restart flow.exe
and it made no difference.
Any progress on this?
This makes it hard to used linked modules with flow, e.g. yarn link.
I can confirm flow fails to find a module that exists in node_module
as a perfectly valid symlink created through yarn link
. Node has no problem require
-ing it.
this turns out really painful to deal with in complex codebases
This will also prevent flow types from working in development for dependent packages in yarn workspaces.
I've just encountered this, in the context of using yarn link
to work on an app and a related module.
It would be really nice if flow could follow yarn link
links.
It turns out that the workaround in #164 works for me (on Linux) - stop and restart the flow server after setting up the yarn link
.
Ideally flow would notice without a restart, but at least there is a workaround.
Stopping and starting flow resolved this issue for me
using flow check
works for me
@andiwinata Why do you post a comment if you don't have this issue??? The 2nd guy who tells us that they don't have a problem. Did you test THIS specific problem? Did you check with the test project included in the initial comment (and follow the instructions to reproduce!)?
hi @lll000111 , my bad, sorry about that.
I was searching for issue about yarn link
and this issue popped up, and saw the comment about restarting flow
fixed the issue - which is true. Thus I commented using flow check
will work too since it seems using new flow server every time it runs.
Again sorry for hijacking your issue
@andiwinata
the comment about restarting flow fixed the issue - which is true
THIS issue, or your issue? As I said, did you try to reproduce this issue?
Does not work for me either
Windows 10/
"flow-bin": "^0.77.0",
"flow-typed": "^2.5.1",
The .flowconfig
module.name_mapper='^web_common' ->'
cannot process
import {something} from 'web_common/Someting';
The symlink on windows is
<SYMLINKD> wc.src [..\..\..\web.common\wc.src\]
under src/
(I also tried
module.name_mapper='^web_common' ->'<PROJECT_ROOT>/src/wc.src'
)
I have gotten this work on windows.
The [include] option in the .flowconfig has to point to the physical directory associated with the given symlinked directory
Notice, now in my updated .flowconfig the directory in the the [include] option points to the actuall (relative, but not symlinked) location.
[ignore]
.*/node_modules/.*
.*/build/.*
config-overrides.js
.*/src/registerServiceWorker.js
.*/src/index.js
.*/config-overrides.js
[include]
../../web.common
[libs]
flow-typed
[lints]
[options]
all=true
module.system.node.resolve_dirname=node_modules
module.name_mapper='^react-native' ->'node_modules/react-native-web'
module.name_mapper='^web_common' ->'src/wc.src'
esproposal.decorators=ignore
esproposal.class_static_fields=enable
esproposal.class_instance_fields=enable
suppress_type=$FlowIssue
suppress_type=$FlowFixMe
[strict]
@vladp that was my issue as well https://flow.org/en/docs/config/include/
Most helpful comment
This will also prevent flow types from working in development for dependent packages in yarn workspaces.