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

Bloomberg TS5.5-beta feedback #58523

Open
1 task done
murtyjones opened this issue May 13, 2024 · 1 comment
Open
1 task done

Bloomberg TS5.5-beta feedback #58523

murtyjones opened this issue May 13, 2024 · 1 comment
Labels
Discussion Issues which may not have code impact

Comments

@murtyjones
Copy link

murtyjones commented May 13, 2024

Acknowledgement

  • I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

We are in the process of evaluating the impact of TS 5.5 beta on Bloomberg code. Below are preliminary findings.

Overall this looks to be a low-impact release. The following changes were observed and seem to either be benign in nature or else improvements:

Change Impacts Release notes Packages affected
Stricter type-checking of partial objects Type checker This may be caused by improved type predicates 1
Improved narrowing of Array.isArray result Type checker This may be caused by improved type predicates 1
Exports are hoisted to the top of a module Emitted JS Not announced Most

Stricter type-checking of partial objects

We observed one project with a new type error in 5.5-beta, seemingly due to an improvement in type-checking for partials.

A minimal reproduction is here.

Improved narrowing of Array.isArray result

We observed for one project a new type error from trying to compare a string with an array after an Array.isArray check. The generics involved make a minimal reproduction infeasible but the essence of the code is:

if (Array.isArray(foo)) {
     If (foo !== "something") // raises a new error for some complex foo
}

Exports are hoisted to the top of a module

Module exports seem to be hoisted to the top of modules now. No runtime impact observed.

Object.defineProperty(exports, "__esModule", { value: true });
+exports.foo = foo;
 function foo() {
     // …
 }
-exports.foo = foo;
@Andarist
Copy link
Contributor

Stricter type-checking of partial objects

My educated guess is that the observed change was caused by the work done in #57946 and #57549

Improved narrowing of Array.isArray result

I don't think type predicate inference could change this anyhow. That change focuses on inferring some functions as type predicates. Array.isArray was already a type predicate - it's declaration is defined in a lib file.

@RyanCavanaugh RyanCavanaugh added the Discussion Issues which may not have code impact label May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Issues which may not have code impact
Projects
None yet
Development

No branches or pull requests

3 participants