Move away from Flow? about import-js HOT 14 OPEN

I think they contain Flowscript, right? I don't use much TypeScript myself but I would be okay with switching over. If I was the only maintainer I would probably just use straight javascript but I can see the benefits of types.

from import-js.

Oh, I thought Flow was a layer on top of TypeScript. Full disclosure; I've never worked actively in either. My ignorance is showing :-)

If I was the only maintainer I would also go for straight vanilla JavaScript. Because that's what I know best and am used to.

So maybe there's a discussion to be had about Flow. I think I saw @lencioni mention in a comment he might want to move away from it.

What other people would be interested in this conversation?

from import-js.

I can't speak for @lencioni but I I'm pretty sure he would suggest we use TypeScript. But then again, I don't think he cares too much since he's not using the project himself.

I would be in favor of using plain old javascript, for a few reasons:

• More people can contribute
• No need for a build step (simplifies things)

I would need some time to ramp up with TypeScript, updating my dev environment, reading up on best practices, etc. And I'd prefer not to do that right now. But that's my laziness talking, I'm okay getting my hands dirty with some types as well. 🙂

from import-js.

While I also have some of that "getting up to speed" on TypeScript, I think the biggest selling point of using plain old JavaScript is that it is the de-facto standard. It is the subset that everybody knows. I also appreciate shedding some weight considering tooling (build steps etc)

Meanwhile, a strong selling point of typed languages is to catch bugs early, another is to add IDE assistance. I use tests for finding bugs, and as a Vim user, I don't need all that sugar.

That being said, if TypeScript is the way to go then I'm fine with that. Probably won't be me refactoring the codebase though ;)

from import-js.

I think we should move this project to TypeScript. Beyond what's already been said, there are a few more reasons:

1. We already have Flow type annotations, so the conversion to TypeScript should be a little easier from the current state.
2. Getting your feet wet with TypeScript would be easiest in a smaller, non-critical project (like this one) so I think it is the ideal opportunity for both of you.

I use tests for finding bugs

Types will find more bugs than tests, and it will find them more quickly, as you mentioned. Tests are still important with TypeScript.

Type annotations also help with the understandability of the code, even if TypeScript was not running any type checking. This makes it easier for new contributors to be productive, assuming they are familiar with TypeScript or similar concepts from other languages.

as a Vim user, I don't need all that sugar.

@trotzig also uses vim, and full TypeScript support can be added via CoC, which adds support for language servers. This is a powerful feature that extends beyond just TypeScript, and is well worth checking out even if we decide to not use TypeScript here. https://github.com/neoclide/coc.nvim

I think the biggest selling point of using plain old JavaScript is that it is the de-facto standard. It is the subset that everybody knows.

And though JS does work out of the box and is what everyone knows, the industry has largely moved to TypeScript already and I expect this trend to continue. The 2022 State of JS survey results show that most people were using TypeScript in 2022 and when the 2023 results are published I expect this to increase.

No need for a build step (simplifies things)

FWIW there currently is a build step that runs Babel. It may be possible to remove it entirely without breaking folks. That said, adding TypeScript to the build step is not much work and should run pretty quickly in this repo.

I am happy to help get things set up.

That said, I expect the two of you to be contributing more to this project than I will, so I'll leave the final decision to you.

from import-js.

Thank you for taking the time to lay out these points so clearly for us. They are much appreciated!

So it seems I and Henric are ambivalent, and you are a strong proponent of TypeScript. So that should settle it. I'd say, let's go with TypeScript.

If Henric agrees, Joe would you like to spend some time converting the codebase to TypeScript once we've merged the other PRs? I think this might be a decision point, as we are perhaps a bit too novice to take on that initial task. I'll be happy maintaining it though.

As an aside, some reflections:

industry has largely moved to TypeScript already

This got me curious. I'm not coming to the same conclusions as you are. The graph from State of JS seems to tell me that people who do work with TypeScript are adamant about using only TypeScript, but not necessarily that most projects are based on it. Having a look at other sources such as Github Language Stats, TIOBE index and Statista it is clear that JavaScript is ahead of TypeScript, both in terms of activity and size of the codebase. Doesn't mean it's a great indicator for picking what language to use though.

TypeScript support can be added via CoC

I did spend a decade with C# and Visual Studio, so I'm quite used to typed languages, popups and autocomplete. Did try a few other plugins for Vim for that in the past but nothing stayed with me. I'll give this a try today, perhaps I'll be happily surprised 😄

from import-js.

I also appreciate the attention to details and for laying out the land @lencioni.

One thing that bothers me is that every time I've started working on a TypeScript project, I end up abandoning Vim for Visual Studio. The tooling just hasn't felt right (Even CoC). Could be different now but it would be annoying to work on this project in Visual Studio for something that I eventually end up using in vim.

from import-js.

I am happy to get TypeScript set up in this project, but I don't want to force it on you here. Let me know when you are ready to give it a go.

from import-js.

@lencioni in your experience, since you are a TypeScript user -- does TypeScript help solve the same thing that import-js attempts to solve? I'm thinking with types, the editor will know a lot more about what can be added, and can therefore auto-import more easily.

If TypeScript makes import-js redundant, then there might be a point in keeping import-js free from types. Dogfooding, in a way.

from import-js.

I'm still on the fence about moving to TypeScript. On one hand, I have a growing curiosity and some drive is building up to try it out, but on the other hand, going to plain old JavaScript feels like something of a relief. So I will support any outcome on this (except maybe keeping Flow 😄 )

Either way, I'm happy we are all engaged and invested in keeping this project alive and well.

from import-js.

When working live with new code ala npm link the build step annoys me a little. Maybe there's some workaround where the build isn't needed? If not, I think of this as one small point in the direction of avoiding build-steps. Just another 2 cents.

from import-js.

It is possible to use typescript in regular js files by adding type annotations in jsdoc comments. It's a bit clumsy and not quite as full featured, but would work if type safety without a build step is desired.

from import-js.

Interesting. I looked at type annotations, but as you mentioned, it seems clumsy and lengthy, which might make it a hard sell.

from import-js.

I would like us to decide on this topic, and not let it linger for a long time. Otherwise, the status quo will prevail and we end up with an implicit decision on partial Flow support, probably the least desirable option.

I want to do some work on ImportJS. I currently have the time and interest for it (especially plugin support), but I'm holding back waiting for this issue to be resolved.

Do we need to identify decision criteria to move forward? Does it come down to authority, or something else, maybe the one with the strongest will to move forward?

from import-js.