-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[RFC] Migrate Jest to TypeScript #7554
Conversation
For me it just doesn't make sense. You will invest a lot of time and will get a bit better autocomplete (I know you may get more features). But in the end of the day it's the same javascript full of its problems. For me I see the sense in moving to reason or ocaml which are more safe languages than both flow and typescript. |
I think that's probably a step too far in terms of time + commitment for value. I think it would make a lot of sense for a reason testing library to take a bunch of the best ideas from jest and re-apply them in their own context. Personally, I've been a part of migrating all of Artsy's JavaScript to TypeScript, and while it's a little bit of churn at first (notably the While I'll be sad to see my main test-bed for the flow for vscode extension go away, it'll be great for exploring and understanding the jest codebase (both as an occasional contributor, and definitely as someone who uses the sub-packages) |
Flow has recently been putting lots of effort into rolling out support for Microsoft's Language Server Protocol (search "LSP"), which from waht I understand should allow it to provide the same level of integration into most IDEs that TypeScript does.
Not sure "safer" is the right word here... in my experience Flow typings are generally more sound and expressive than their TS counterparts. Agreed there are certainly more definitions available though.
Not sure I understand this point - what's the difference from Flow & flow-typed?
Imo jumping between TS and Flow does not create much of a barrier for someone experienced with either. Like you say, the features and syntax are extremely similar. Another con:
|
@orta already answered here, but the tl;dr (at least to me) is that the point here is to make the code base more approachable to to new (and old) contributors who are consumers of Jest. The vast majority of them are JavaScript developers, not OCaml developers.
True, but we love it nonetheless 🙂
Sure, but it's taken months and months, and it's still not done. The argument "we'll be just as good, just a year later" doesn't really spark much confidence. Happy to be convinced otherwise of course. Also, FWIW I personally don't use VS Code, so LSP doesn't impact my experience. I use IntelliJ (WebStorm), and their TS support is miles ahead of the Flow support. I know most people do use VS Code nowadays though, so your point is very much valid to the majority.
There is no way to generate typings from source code in flow. They've had an untouched
Sure, but the tooling is way better with typescript, even if the syntax itself is very similar. The fact flow is improving (lsp support has been worked on for a long time, generating types etc) doesn't mask the fact TS has all of that today, and there's no real reason to believe Flow will get those features in a timely manner.
I can't answer to a, but to b: not necessarily, this took 8 months facebook/flow#6103, typescript had it within a few days DefinitelyTyped/DefinitelyTyped#24624 |
Note that TS has been getting a lot better since they started introducing the various |
I feel like a lot of the IDE support actually is done now. The LSP mode just landed as default 9 days ago. In my experience, it works smoothly.
Hmm, does IntelliJ not have support for plugging in LSP? That seems a more scalable and robust approach than them writing in-house tooling for every language extension.
Agree this is a big pain point. Perhaps someone on the Jest team can help flag this up internally at FB and get help get this more attention?
Imo this just highlights the difference in philosophy between TS and Flow (which is healthy for the ecosystem). TS added a few lines of typedefs, which include introducing 4 Fundamentally I just think having the competition of two popular type systems is good for the JS ecosystem as a whole. So it's nice that there are some projects firmly planted on either side (Flow: FB products such as React, React Native, Jest, Relay, etc; TS: Microsoft products, Angular, etc). Remember that when Flow was first released, TS didn't even have support for null checks. The two have both been introducing new ideas, taking lessons from each other, and helping push the space forwards (TS from an OOP background encouraging pragmatism, and Flow from an algebraic data types background encouraging correctness). Imo it would be a shame for the ecosystem to become completely dominated by one type system, and lose the innovation and cross-pollination that the other is bringing to the table. |
I think this is a great idea! just a note Vuejs is also moving to TypeScript |
As a Flow to TypeScript convert, I will always agree with any such proposal. That being said, the time required to migrate an entire codebase is quite high, as it took me many months to convert all of my own projects, and the same at my employer. Doing it piece meal can also be quite confusing, especially if the conversion takes a lengthy amount of time (which it probably will). |
@NoHomey @jwbay @asvetliakov @alexjoverm @epicallan @ikatyang @wsmd @JamieMason @douglasduteil @ahnpnl @JoshuaKGoldberg @UselessPickles @r3nya @Hotell @sebald @andys8 Sorry about the mass-tag (and some of you might already have responded to the OP) 🙏. As you're all set up as maintainers of General feedback would be lovely (as well on thoughts about the process/transpiling part), but in particular I'm not sure if it makes sense for us (Jest core) to maintain the main Jest typings (for assertions etc) in this repo. It'd be coupled to Jest's release cycle, which is at times pretty slow. But at least all the types for transformers, config etc can come from here (a quick look through of |
@milesj did you use babel 7 as your transpiler during the migration? I recently completed migrating a flow-typed module to typescript, and using babel 7 with |
@JM-Mendez On my personal stuff I used TS itself, while at work we used Babel 7. Definitely easier when using Babel. |
We've decided to go for this, thanks a bunch for your feedback! Right now, the plan is to release Jest 24 stable (should be any day now, https://github.com/facebook/jest/milestone/8 (please install After that, we want to do 2 things for Jest 25: simplify our configuration (#7185) and migrate to TypeScript. As part of migrating to TS, we will be moving to ESM all over (tried to do it for Jest 24, but it broke lots of stuff, see #7602 and #7608). So we also need to make sure our exports do not mix default and named exports, so that we can use https://www.npmjs.com/package/babel-plugin-add-module-exports. That will also resolve #5803 and #7109. However, it'll likely be a breaking change, so putting it in a major makes sense. I'll open up a tracking issue once we're ready to start migrating, at which point help from the community in actually migrating would be awesome 🙂 We'll hopefully be able to use https://github.com/bcherny/flow-to-typescript, which should remove a lot of the manual migration work. |
Not to turn this into a bikeshed, especially as the RFC has been accepted (:tada:), but I strongly recommend against the Also, make sure to enable |
Thanks for chiming in @Kovensky!
If we do not add it, I don't think we can use default exports (from our module entrypoints) at all. Forcing consumers to use
We'll be using |
Why not have a special index entry point that re-exports the default so consumers don't have to?
Type checker ( |
Note that using TypeScript has had a custom |
That won't mess up the typing information? The I've just written apps in TS never a library to be consumed as both CJS and TS (and UMD), so I'm not sure how to ensure all of those cases work without having to care about how they're written. So all my questions are in good faith! 😀
How so, the
Hmm, for the docs (https://www.typescriptlang.org/docs/handbook/modules.html):
Doesn't seem like a feasible solution? |
Maybe you can take a look at how ng-packagr builds packages ? I'm using it to create Angular packages. It helps to generate esm, fesm and umd as well. |
This was a problem with Chalk for a time. Their d.ts file indicates I'm not expressly discouraging you from using |
Using Either way - declaring one shape (in the types, and possibly exporting it too from ESM entry) and having different in CJS/main entry might lead to some really obscure situations and bugs. While Unfortunately CJS & ESM interop is a mess 🤷♂️ |
Yesterday on HackerNews: "Porting 30K lines of code from Flow to TypeScript (davidgom.es)" HN discussion: https://news.ycombinator.com/item?id=18906405 As a heavy Flow and occasional TS user, I found the writing not too long, balanced and informative, so it may be of interest in the current context. PS: By the way, I came here from this HN discussion posted today. |
BTW Do seriously look at the generated code from TypeScript its not very nice as compared to the type erased code from Flow. |
We'll be using babel to transpile, so it'll look the same as our current code does. |
@orta @ciszak Or, if you renamed without using |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Please don't discuss transpiled output from Also please don't discuss ways to keep git history in files - this issue should be focused on the the why's of the migration to TS, not the how's (at least not at that level - gotchas from other experiences migrating code is of course welcome! 🙂). |
Thank you so much. Type safety in tests is a huge boost of productivity, especially when creating mock objects. Speaking of which, here's a shameless plug for a thin wrapper library I wrote that keeps your mocks typesafe. If it's of any use the core Jest team (@SimenB, et. al.) then I would be happy to fold it into Jest and to deprecate my library. :) Until then, maybe some of you will find it useful. :) |
Jest 24.1.0 is out, so I've opened up a tracking issue for the migration: #7807. Any help and feedback people can provide is very much appreciated 🙂 |
@dgreene1 sorry, I somehow missed your comment! I think it is type safe now, though? We've copied over from DT, which relatively recently landed it (DefinitelyTyped/DefinitelyTyped#32579 and a bunch of follow-ups/linked issues) You're more than welcome to go through our implementation and see if it can be improved: https://github.com/facebook/jest/blob/5ba35be3ef64090bae5e04f51fd170529fba3d1a/packages/jest-mock/src/index.ts |
As a follow-up to this - we've successfully completed the migration of all packages. An alpha has been published as |
@SimenB How did you migrate such a big codebase would be an interesting subject for a blog post 😉 |
Yeah, @cpojer said the same... I'll be writing one, no promises about when though |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
In the lastest State of JS, the one stat that stood out to me was the number of people either using or wanting to use TypeScript (over 46.7% has used and will use it again, 33.7% wants to learn it). And since Babel 7 has support for TypeScript, integrating it into your workflow has become way easier than it used to be.
We, the Jest core team, have privately discussed migrating to TypeScript (Jest is currently written using Flow), and I was asked to look into how much effort it potentially is, and try to gather feedback from the community. So, as a proof of concept, I've migrated
pretty-format
over (look at the second commit of this PR).This PR is a request for comments from the community. Is it a good idea? Is it wasted effort?
While comments on the code itself (and the build process) is welcome, that's not really the point of this particular exercise.
The PR will probably not pass CI (at least linting), but that should be fixed by babel/babel-eslint#711.
From my personal (and limited) experience, the two type systems are pretty similar in feature sets and syntax, so I haven't consider which of the 2 type systems are better. This is about improving the health and maintability of the code base and encouraging contributions.
I'll try to list out the pros and cons of going Flow -> TypeScript from the top of my head - not by any means an exhaustive list!
Pros:
@types/jest
has 1M download every week) and for Jest's individual packages, such asjest-worker
andjest-haste-map
Cons:
Other libraries doing the same:
I'm sure one can find evidence of going the other way as well, those are just the ones I know about, and presented as anecdotal "evidence".