Flow-runtime runs on cached location of files even if they have been moved

[scolacur]

This is a:

• [x ] Bug Report
• [ ] Feature Request
• [ ] Question
• [ ] Other

Which concerns:

• [x ] flow-runtime
• [ ] babel-plugin-flow-runtime
• [ ] flow-runtime-validators
• [ ] flow-runtime-mobx
• [ ] flow-config-parser
• [ ] The documentation website

---

What is the current behaviour?

If I move a folder from one directory to another, flow-runtime doesn't see the new location of the .js files in that folder. This causes flow-runtime to error out if any of these .js files have dependencies using relative paths. It seems to be looking at a cached version of the .js files in the original folder location.

Example: Initial folder structure:

common/ --components/ ----dropdown/ ------index.js ------styles.css apps/ (on same level as common)

Run flow: -> no errors Run application with flow-runtime: -> no errors.

If I move the dropdown folder into apps, creating this new folder structure:

common/ --components/ apps/ ----dropdown/ ------index.js ------styles.css

Run flow: -> no errors Run application with flow-runtime: -> Receive this error:

ERROR in Flow: Type Error

Error: common/components/dropdown/index.js:6 ./styles.css. Required module not found

Found 1 error

webpack: Failed to compile.

My current workaround is to re-create the original folder structure with blank files. Eg. I'd create a new folder in common/components called 'dropdown', then create an 'index.js', leave it blank, then run flow and flow-runtime again. Flow-runtime sees that the file is blank and throws no errors. Then I can delete this folder afterwards. But this is sort of silly to have to do.

---

What is the expected behaviour?

Flow-runtime should keep an up-to-date version of the project's folder structure

Which package versions are you using?

0.14.0

[phpnode]

@scolacur this is a strange one, what command are you running with flow-runtime-cli?

[scolacur]

I'm not using flow-runtime-cli, just running my application with flow-runtime 0.14.0 and babel-plugin-flow-runtime 0.11.1

On Mon, Nov 13, 2017 at 1:19 PM, Charles Pick [email protected] wrote:

@scolacur https://github.com/scolacur this is a strange one, what command are you running with flow-runtime-cli?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codemix/flow-runtime/issues/163#issuecomment-344061808, or mute the thread https://github.com/notifications/unsubscribe-auth/ALXVtyoNKY6kjhTo21441EEbk2453HZqks5s2LJ4gaJpZM4QAAV8 .

-- http://leafgroup.com

Steve Colacurcio Software Engineer

[email protected]

1655 26th Street CA 90404 United States leafgroup.com

-- Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Leaf Group. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

[phpnode]

@scolacur really strange then as flow-runtime doesn't really know about file locations. I wonder if this is related to webpack's caching

[jackric]

EDIT - I figured out this problem is not cache related; it's Flow's type inference. I have a doubly-nested array and Flow infers the type for element 2 onwards from the first element. Leaving my original comment for anyone searching in future.

Running into a similar problem - RuntimeTypeError in the browser relating to a field I had removed from a type definition long ago.

What's very surprising is opening all of the js files loaded in that window, and searching for the field name, yields 0 matches. I must assume that the field names are being carried in some non plain-text form (base64 of gzipped data etc)?

Also can't locate any plausible build cache containing the field name - after grepping my entire home directory.

Happy to provide more details if you know where I should be digging...