fix: issues with import type conversion on recent versions of @babel/traverse

[jedwards1211]

fix #254

[jedwards1211]

This at least works around the issue in babel path caching right now. The way there's a global cache of paths in @babel/traverse is kind of horrifying.

[gajus]

@jedwards1211 What's your NPM? I will add you as an owner to NPM and GitHub.

[jedwards1211]

Okay thanks! Also jedwards1211 on npm

[jedwards1211]

@gajus just curious, did you stop using flow-runtime for validation in your own projects? I'm still kind of stuck with it for the time being 🙃

[gajus]

I gave up on Flow altogether.

It is clear that Facebook gives 0 💩 about the community.

It is sad because I, even after using TS for a while, prefer Flow. But I would not pick it for a commercial project.

I am slowly rewriting all my packages to TS.

You've been added to NPM and GitHub.

[jedwards1211]

Yeah it's a shame...btw you might be interested in my typescript-validators package as a replacement for validation via flow-runtime, (unless you already found something better for that purpose?). It's actually based on some guts of the flow-runtime sub package, but doesn't require any kind of babel plugin.

[gajus]

Cool! I stargazed it. 👍

And yes, it is a shame. Flow had a lot of potential. But seeing that they completely dropped any efforts to support the community, there is simply no future for it.

I find runtime validation mostly useful when working with external data. We don't do that much in the current venture that I am involved.

[jedwards1211]

@gajus did you ever figure out how to get lerna run lint to work in this repo?

I see a lot of flow errors because it can't resolve packages that wind up in the workspace root node_modules. I don't understand how it was ever working unless Charles Pick was installing deps in each subpackage independently during development.

[gajus]

It has been too long sorry.

The last time I was working with it, I remember ending up rewriting large chunks of code to make it work. Unfortunately, those commits never saw the library since I lost my laptop. 🤷‍♂️

So unfortunately, I only remember that it wasn't straightforward.

[gajus]

For what it is worth, if you are going to work on this, we can create issues for each thing and assign some monetary reward through #207. They offered to sponsor development of flow-runtime. This was a few months back, but I am happy to reach out.

[jedwards1211]

I see. Well, I'm hesitant to get too in the weeds on some issues, for a long time I've thought flow-runtime was over-ambitious, and I've never really liked the idea of turning type annotations into runtime validations everywhere, rather than just at API boundaries. If I even stick with Flow in the long run I would want to eventually migrate to something that feels more futureproof than flow-runtime... It's just in the short term I'm stuck with it so some effort to keep flow-runtime working is worth the effort for me.

[gajus]

I understand. I was in a similar boat.

[jedwards1211]

Man just trying to fix flow errors in the flow-runtime package I'm about ready to give up, it's a colossal steaming mess. Trying to implement runtime assertions for type parameter application, annotated function values, etc. was a mega bad idea. Runtime checks only have a point at API input boundaries or places where you need to do something too dynamic for compile-time checks. And you're not going to be checking annotated functions at API input boundaries. And not even graphql has implemented parameterized types for example.
I think even Charles Pick came to realize this was a mistake. He did tell me he abandoned flow-runtime in favor of simpler validation approaches in his own projects.

[jedwards1211]

I honestly think it's better for everyone if we officially deprecate the project, because we know no one's ever going to have a good reason to fully fix and maintain it.

[gajus]

I hold the project with the hope (however unlikely) that Flow will rebounce. I would personally benefit from a project such as flow-runtime succeeding, and would be willing to invest into the development of the project at a future time.

As it stands though, as I do not use Flow in my current work place, I do not have capacity to support Flow.

[jedwards1211]

I think it would be better to start over with a less ambitious format though where runtime type generation and assertions are always opt-in and don't intend to support everything.

Btw, I just figured out enough of how to implement flow type defs for typescript-validators that I'm about to publish it as typed-validators with types for both, and use that. Though Flow flakes out on expected errors sometimes when the types are complex enough 😕