Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move away from Flow? #593

Closed
mikabytes opened this issue Jan 18, 2024 · 14 comments
Closed

Move away from Flow? #593

mikabytes opened this issue Jan 18, 2024 · 14 comments
Labels

Comments

@mikabytes
Copy link
Collaborator

mikabytes commented Jan 18, 2024

This project uses .js extension for files that include TypeScript. This confuses some editors, mine included. Perhaps we could change them to .ts? I was confused :-)

Let's discuss whether or not to move away from Flow, and what to move towards.

@trotzig
Copy link
Collaborator

trotzig commented Jan 18, 2024

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.

@mikabytes
Copy link
Collaborator Author

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?

@mikabytes mikabytes changed the title TypeScript files with .ts extension ~~TypeScript files with .ts extension~~ Move away from Flow? Jan 18, 2024
@mikabytes mikabytes changed the title ~~TypeScript files with .ts extension~~ Move away from Flow? Move away from Flow? Jan 18, 2024
@trotzig
Copy link
Collaborator

trotzig commented Jan 18, 2024

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. 🙂

@mikabytes
Copy link
Collaborator Author

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 ;)

@lencioni
Copy link
Collaborator

lencioni commented Jan 18, 2024

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.

@mikabytes
Copy link
Collaborator Author

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 😄

@trotzig
Copy link
Collaborator

trotzig commented Jan 19, 2024

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.

@lencioni
Copy link
Collaborator

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.

@trotzig
Copy link
Collaborator

trotzig commented Jan 22, 2024

@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.

@mikabytes
Copy link
Collaborator Author

mikabytes commented Jan 24, 2024

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.

@mikabytes
Copy link
Collaborator Author

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.

@lencioni
Copy link
Collaborator

lencioni commented Feb 3, 2024

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.

@mikabytes
Copy link
Collaborator Author

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

@mikabytes
Copy link
Collaborator Author

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?

lencioni added a commit that referenced this issue Jun 7, 2024
We know that we do not want to use flow anymore. We may want to adopt
TypeScript, but it is unclear if we will in the near term.

#593

I want to re-introduce ESLint, and instead of setting up ESLint to be
able to parse flow syntax, I decided that we should just remove it.

#608

I removed these annotations by running the following command:

```
npx flow-remove-types lib/ -d lib/
```

Then I formatted the files by running prettier on everything:

```
node_modules/.bin/prettier -w lib/
```

I think if we wanted to introduce TypeScript that it might be easier to
do it from scratch anyway instead of attempting to convert the flow
types over to a different type system.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants