What's New for TypeScript and F#
Microsoft updated tools for its functional programming-oriented F# language and announced a beta for the milestone TypeScript 4.0 release scheduled for Aug. 4.
Here's a look at what's new for each language:
TypeScript 4.0 Beta
TypeScript 3.9 just shipped about seven weeks ago, featuring faster compile times and much more. Now it's on to v4.0 for the dev team, with program manager Daniel Rosenwasser reassuring developers the new release won't contain any more breaking changes "than usual."
"Our philosophy in evolving TypeScript has always been to provide an upgrade path that minimizes disruptive breaking changes while still giving ourselves some flexibility to flag suspicious code as errors when appropriate," Rosenwasser said in a post last week. "For this reason, we're continuing with a similar versioning model to that of past releases, so 4.0 is just the natural continuation from TypeScript 3.9."
New stuff in v4.0 includes:
- Variadic Tuple Types: Spreads in tuple type syntax can now be generic, and spread elements can occur anywhere in a tuple -- not just at the end.
- Labeled Tuple Elements: Tuples types can now provide labels, and the syntax for rest elements and optional elements now mirror that of parameter lists.
- Class Property Inference from Constructors: TypeScript 4.0 can now use control flow analysis to determine the types of properties in classes when noImplicitAny is enabled.
- unknown on catch Clauses: Developers can now specify the type of catch clause variables as unknown instead of the default any, which caused some undesirable behavior in certain situations.
- Custom JSX Factories: Coders can now customize the fragment factory through the new jsxFragmentFactory option. Fragments are a type of JSX element that allows for returning multiple child elements.
- Speed Improvements in build mode with --noEmitOnError: TypeScript 4.0 changes gives a great speed boost in scenarios such as when compiling a program after a previous compile with errors under --incremental, which would be extremely slow when using the --noEmitOnError flag.
- --incremental with --noEmit: TypeScript 4.0 allows developers to use the --noEmit flag while still leveraging --incremental compiles. This was previously not allowed, because --incremental needs to emit a .tsbuildinfo files; however, the use-case to enable faster incremental builds is important enough to enable for all users.
- Editor Improvements: These are dependent upon what editor is being used.
- /** @deprecated */ Support: TypeScript's editing support now recognizes when a declaration has been marked with a /** @deprecated * JSDoc comment.
- Partial Editing Mode at Startup: The team is working on a new mode for editors to provide a partial experience until the full language service experience has loaded up. This addresses slow startup times usually caused by the project loading process.
- Smarter Auto-Imports: In editor scenarios, TypeScript 4.0 works to include any packages developers have listed in their package.json‘s dependencies field. This addresses problems associated with scenarios when auto imports don't seem to work.
The post also details three breaking changes, including the deprecation of TypeScript's Node Factory.
F# 5 and F# Tools Update for June
This builds upon the F# 5 preview announced in March and further updates announced in the May Build developer conference.
The new updates include:
- Improvements to nuget references for F# scripts: The team enhanced support for
#r "nuget:...", specifically enhancing it to support packages that pull in native dependencies.
- Better interop with nullable value types: "Nullable (value) types (called Nullable Types historically) have long been supported by F#, but interacting with them has traditionally been somewhat of a pain since you'd have to construct a Nullable or Nullable<SomeType> wrapper every time you wanted to pass a value. Now the compiler will implicitly convert a value type into a Nullable<ThatValueType> if the target type matches."
- Improved stack traces in F# async and other computation expressions: Community contributor Nino Floris was thanked for work resulting in stack traces coming from caught exceptions in computation expressions (such as F# async) being able to retain more information.
Having resolved some longstanding design issues, the F# team is working on some other future improvements, though they can't be used in .NET 5 yet. They include:
- F# quotations improvements
- Finishing up nameof
- Open type declarations
- Allow implementing the same interface at different generic instantiations
- F# and VSCode notebooks
- .NET Framework projects default to SDK-style project files
All of the above and much more is detailed in a June 26 blog post authored by Phillip Carter, program manager for .NET and Languages, who said the F# dev team is focusing on three things for v5:
- Continuing inclusion of language features when their design and implementations are stable
- Continuing to improve the tooling performance for larger F# codebases
- Making F# in Jupyter and Visual Studio Code Notebooks the best language for data science and analytical work
"Later this year we will 'close down' on F# 5, marking a period of time where we focus on stabilization and planning for the next F# language version," Carter said. "We don't have a date in mind for that year, but we're thinking it will be near the end of the summer."
David Ramel is an editor and writer for Converge360.