Hi guys,
I installed last version of flowtype (0.33) as local dependency (npm install flow-bin --save-dev) and I configured the property flow.pathToFlow but when I opened a js file vscode returns the error:
[Flow] Cannot find flow in PATH. Try to install it by npm install flow-bin -g
That's my .vscode/settings.json:
{
"javascript.validate.enable": false,
"typescript.validate.enable": false,
"javascript.validate.syntaxValidation": false,
"javascript.validate.semanticValidation": false,
"flow.pathToFlow": "./node_modules/.bin/flow"
}
If I installed globally flowtype the extension works fine, but I want setup flowtype as local dependency!
Do you have any suggestion?
Best regards
Gianluca
Try using a full path instead of a relative one.
For example: ./node_modules/.bin/flow -> /Users/user_name/npm_package/node_modules/.bin/flow
I think it'd be nice if this extension picked up the local flow-bin when available by default. Then the users wouldn't need to install it globally.
@chrisblossom If we use a full path, we'll need to edit this setting for every projects.
I also use purescript's support for vscode and they allow to point to the local node_module's .bin directory as an option.
I think it would be great to have this option too for flow. :+1:
This is especially important when working on several projects that don't share the same config version due to changes introduced in the new releases of flow-bin.
FWIW, for Windows users this works by using c:\\path\\to\\package\\node_modules\\.bin:flow (via where.exe pattern matching).
Edit: never mind, this fails, because pathToFlow is used for executing the command without usage of which/where. @gabelevi @Arilas is it possible to spawn where/which first to get the path to flow, and then execute the latter? Alternatives could be adding a localPathToFlow property or do some kind of matching on pathToFlow to determine if it's local. If you know it's local, I think you can use where /R and it might work.
It's useless to have an absolute path in "Path to Flow" setting, as projects can be shared across multiple users, and multiple OS's. Shouldn't this line use something like node's path.resolve() to get the flow wherever it is instead?
@WhyEvenTry please tone down your passive aggressiveness. Perhaps saying "pathtoFlow is redundant" would have been better than "...useless". I'm not trying to point out the obvious that this doesn't work. Even after 2 months+, the workaround (global installation of flow) is the only way to get this to work. As I understand it, the pathToFlow setting should be able to point to the local installation of flow, not the global one. The global one can be added by the user to the environment path anyways, so in most cases it doesn't matter. If a project needs to be shareable, the ways to have flow are two:
.flowconfig can be easily synced with the local flow version, and so on.@WhyEvenTry also, please consider your tone, I also agree with @kumarharsh that it is not the way I'd like communication to go on this repo.
As an update for everyone, I have an active PR specifically dealing with this issue https://github.com/flowtype/flow-for-vscode/pull/53
@WhyEvenTry you don't need to react this way, you're just making things worse for everyone reading this issue. I see your point, but you don't need to be so aggressive about it. Rage produces more rage. You can react and point out why you don't agree in a much more productive and clear way if your comments aren't filled with rage.
Anyway... just my 2 cents. I think most people don't want to read this type of discussion.
@WhyEvenTry please stop trolling so unashamedly. You even went ahead and created a fake account (@LionessLover), just to troll? I think by this time, it is very clear to everyone what you're trying to do.
@orta / @gabelevi can you lock this thread if possible?
Sorry - was travelling.
No problem, this thread can be closed, and locked. My PR is merged which should fix this problem once we ship a deploy to VSCE.
@WhyEvenTry - Here is some advice and a warning. This thread is still locked, so a response is not expected.
It is ok to disagree with other members of the open source community. It is ok to constructively offer criticism. It is not ok to intentionally insult.
Do you feel attacked after reading a comment? Try assuming that the author of the comment has good intent and is trying to help you. Then re-read with that in mind.
After reading a comment, do you think the author of the comment is stupid? Try assuming that the author of the comment is not stupid. Then debug the misunderstanding. Maybe they don't understand your point or you don't understand their point. Or maybe you are both talking about different things.
When you feel attacked and get defensive, your mind closes. The comment that made you feel defensive might be making some really good points, but you'll miss them since you're just worried about defending yourself.
I saw your abusive comment from yesterday before it was deleted. It was not appropriate and violates general condition 8 of GitHub's terms of service.
This is an official warning. If you continue with this behavior we will block you from the flowtype and facebook organizations. If you abuse other users on GitHub, the abuse will be reported to GitHub.
That said, I hope this warning will be heeded and you will continue to open the high quality GitHub issues that we have seen from you in the past.
Most helpful comment
I think it'd be nice if this extension picked up the local
flow-binwhen available by default. Then the users wouldn't need to install it globally.