Almost every single Flow version upgrade is like this — every new version brings a slew of errors due to Flow’s continuous movement away from practicality towards “soundness”.
Google Feedback on TypeScript 3.5
51–60 of 149 posts
Re: Google Feedback on TypeScript 3.5
#52I love TypeScript. I started using it around v1.0. Microsoft has hit some gold with it. When I first started using it I had lots of `any` in my code (like the Google employee is describing here). But over time it really starts being extremely clean.
I started around 0.7/0.8, it was already such a fantastic product back then. It's just fantastic, Javascript on steroids.
I don't have a significant amount of experience with TypeScript, but even from my limited experience I agree that it's a fantastic product. That said, at $JOB we (unfortunately) have a fair amount of production code written in TypeScript 0.9 which nobody has ever upgraded, and simply won't compile on a more recent version. It's been that way for years now, and every attempt to bring it up to date has been met with failure.
It may be an overly broad request, but I'd be very interested if anyone had any suggestions for how we might go about performing such an upgrade in an iterative manner. My understanding is that pre-1.0, TypeScript went through a number of breaking changes (as would be expected of any pre-release software), but I've never found a complete list of what those breaking changes were.
Re: Google Feedback on TypeScript 3.5
#53A little off-topic: I'm currently trying to find a way to write (type safe) business logic once, then reuse it pretty much everywhere (mobile / web / desktop),and it seems to me that typescript has become the only option. Javascript runtime is present everywhere, and can interface with anything. Does someone knows of another alternative (viable right now, or in the coming months) ? I know llvm can theoretically targe…
Have you looked at ReasonML/OCaml? It certainly compiles well for web (bucklescript) and desktop. I haven't tried it for mobile but I would be surprised if it didn't work well. The ReasonML native tooling (i.e. non-web) is evolving, but it's fundamentally sugar on top of a long solid history of OCaml.
I'd love to have ML expressiveness. The only thing i'm a bit worried about is the I/O abstraction level.
I'm not really looking for a GUI abstraction layer, but i'd like to be able to write to a file, or perform a network request, in a platform-independant way. I'm afraid this requires a little bit more than just a javascript transpiler target.
Re: Google Feedback on TypeScript 3.5
#54Earlier quoted context omitted.
Be careful not to mistake Google's use of a monorepo with consideration of whether $DAYJOB or $FOSSPROJECT should use a monorepo. Google has a lot of tooling and some very thoroughly-considered and reinforced policies and cultures around their use of a monorepo. Trying to use a monorepo without those tools and ingrained policies may not be very likely to lead to similar results.
The default should be keeping code together, and justifying why you are splitting it up, not the other way around. While what you said is true, the codebase of most organisations is not large enough that they run into those scale constraints for a long time. Instead, if you split up your code you immediately get organisational headaches of managing changes across multiple codebases. If you keep it together, the scale…
I think I'd more or less agree with that.
For example, one of the questions I generally ask in a meeting room that's considering this topic, and has for example microservices in flight, is: "Are you willing to put in the work to make Service A support more than one version at a time in Service B?", and if not, then that's a very (very) strong indicator that the level of coupling and lack of organizational boundaries will result in pain from anything but a monorepo.
I prefer to split things up when possible. When it does fit, there's many benefits. There's also the concern that building too much culture and tooling that presumes a lack of splitting of repos can become its own form of trap which becomes increasingly hard to navigate out of, even if you later want to, as the situation self-iterates. But I agree that splitting things out needs justification, and the "default" stance should include that.
Re: Google Feedback on TypeScript 3.5
#55> (I might suggest the underlying problem in this code is relying on inference too much, but the threshold for "too much" is difficult to communicate to users.) This is a very outstandingly interesting line out the whole writeup. I like the writeup in its entirety for being very balanced and thoughtful, but this line in particular really stands out to me as worth more thought for anyone interested in language and typ…
I think the underlying problem is that in cases of long inference chains, it's hard to detect where the problem lies if types on both ends don't match. In my experience, the compiler will just show an error on the "latter" end, then the user needs to trace inference back and figure out where things went wrong. Personally, I experience this quite often, e.g. in Java whenever arrow functions are heavily used, such as w…
Some IDEs show type hints on hover, or if type mismatch is detected, they display inferred types inline in code. E.g Intellij Idea does that for Scala and it is really useful. I wish it did that in Java as well.
Re: Google Feedback on TypeScript 3.5
#56Earlier quoted context omitted.
Did they improve the download size?
No and on that basis it's unusable. However that's because it downloads the whole runtime. Eventually MS intend to load only your compiled code.
You can avoid that issue with the Server Side Blazor concept for business side portions of your application.
Depending on the application you can get extremely far with just using HTTP requests to an API for anything business logic related. A lot of apps over complicate themselves by trying to force a JS framework on the front end with no benefit to the user. I seem to prefer using non-SPAs these days over SPAs because very few places do them well. Google being a terrible SPA developer.
- Edit - I forgot to mention Elixir's Phoenix has LiveView which is similar to Server Side Blazor.
Re: Google Feedback on TypeScript 3.5
#57> (I might suggest the underlying problem in this code is relying on inference too much, but the threshold for "too much" is difficult to communicate to users.) This is a very outstandingly interesting line out the whole writeup. I like the writeup in its entirety for being very balanced and thoughtful, but this line in particular really stands out to me as worth more thought for anyone interested in language and typ…
Just to clarify: you're suggesting I believe that the programmer should be advised by the compiler to add one or two explicit type declarations to certain programs, not that the compiler should refuse to compile any programs that currently compile.
It should be a compiler strictness flag.
Re: Google Feedback on TypeScript 3.5
#58Earlier quoted context omitted.
I started around 0.7/0.8, it was already such a fantastic product back then. It's just fantastic, Javascript on steroids.
I don't have a significant amount of experience with TypeScript, but even from my limited experience I agree that it's a fantastic product. That said, at $JOB we (unfortunately) have a fair amount of production code written in TypeScript 0.9 which nobody has ever upgraded, and simply won't compile on a more recent version. It's been that way for years now, and every attempt to bring it up to date has been met with fa…
So, because it currently "works", it should "safely" compile by adding many `any`s. (No Implicit Any, and other strictness flags set to false.)
Then it's a matter of cleaning them up.
But usually, at least in my experience, the problem is the libraries and their API, which used to be very much full of any in those dark times.
Re: Google Feedback on TypeScript 3.5
#59A little off-topic: I'm currently trying to find a way to write (type safe) business logic once, then reuse it pretty much everywhere (mobile / web / desktop),and it seems to me that typescript has become the only option. Javascript runtime is present everywhere, and can interface with anything. Does someone knows of another alternative (viable right now, or in the coming months) ? I know llvm can theoretically targe…
C# (with .NET Core 3.0 officially launching on the 23rd of September, Blazor (WASM) support is included.) I have been playing around with Blazor a bit with the preview releases and I have to say it's pretty slick.
Does JavascriptCore support running wasm (on ios and android) ?
Also, as i mentioned in another answer, i'm not only concerned about being able to run the code on another platform, but also having it run on an "friendly" environment (with some kind of cross-platform I/O api).
Re: Google Feedback on TypeScript 3.5
#60Earlier quoted context omitted.
I started around 0.7/0.8, it was already such a fantastic product back then. It's just fantastic, Javascript on steroids.
I don't have a significant amount of experience with TypeScript, but even from my limited experience I agree that it's a fantastic product. That said, at $JOB we (unfortunately) have a fair amount of production code written in TypeScript 0.9 which nobody has ever upgraded, and simply won't compile on a more recent version. It's been that way for years now, and every attempt to bring it up to date has been met with fa…
You can see a list of all changes in the "What's New in TypeScript" document on GitHub:
https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
And a list of breaking changes here:
https://github.com/microsoft/TypeScript/wiki/Breaking-Change...
They both go back until v1.1. For older changes you can check the blog:
https://devblogs.microsoft.com/typescript/announcing-typescr... https://devblogs.microsoft.com/typescript/announcing-typescr...
Anyway, it's hard to say what you need to do to get your code to compile on the latest TypeScript version without knowing what some common compile errors are in your code.
Here are some guesses:
1. The way you obtain type definitions for third-party packages has changed. It used to work with /// and tools like nuget or TSD (TypeScript definition manager). But now it works with npm in the @types namespace and some npm packages even include definitions themselves now.
Of course, updating to the latest type definitions would mean that you have to upgrade to the latest versions of the third-party libraries as well. Otherwise you have to find a way to keep working with the old definitions for the respective library versions.
2. Pre-1.5 TypeScript had something called "internal modules" which were renamed to "namespaces" and are generally discouraged now. Hopefully your code is not using that feature.
https://www.typescriptlang.org/docs/handbook/namespaces.html
3. tsconfig.json. I don't remember when they introduced it, but you likely need to create this file and tweak the settings