profile
viewpoint
Denis Malinochkin mrmlnc Yandex Odintsovo, Russia https://mrmlnc.com Panda & TypeScript lover at @yandex

mrmlnc/fast-glob 1049

:rocket: It's a very fast and efficient glob library for Node.js

mrmlnc/material-color 135

:high_brightness: The colour palette, based on Google's Material Design, for use in your project.

mrmlnc/material-shadows 84

:thought_balloon: Mixins for Material Design Shadows

JS-DevTools/readdir-enhanced 67

fs.readdir() with filter, recursion, absolute paths, promises, streams, and more!

mrmlnc/emitty 64

A platform for finding dependencies between files and building tools for incremental compilation or build.

mrmlnc/less-guidebook-for-beginners 17

:book: Книга о CSS-препроцессоре Less для начинающих и продвинутых пользователей.

mrmlnc/hamburger-icon 16

:hamburger: A collection of mixins for creating hamburger icons.

mrmlnc/less-mq 9

:paperclip: Really simple media queries in Less.

mrmlnc/grunt-puglint 5

:boar: Grunt plugin for pug-lint (formerly Jade)

mrmlnc/chrome-vk-commentblocker 4

Расширение для браузера Google Chrome, которое позволяет скрывать и показывать комментарии.

PR opened libuv/libuv

unix: re-allow WRONLY fd in uv_read_start

For the writing end (O_WRONLY) of a pipe(2), we should also allow polling for read, so that the user could listen for a broken pipe on the writing end using uv_read_start() without having to try to write anything to the pipe, or wait until the next write to find out.

Fixes: https://github.com/libuv/libuv/issues/2058

+64 -3

0 comment

6 changed files

pr created time in 13 minutes

PR closed libuv/libuv

unix: re-allow WRONLY fd in uv_read_start

For the writing end (O_WRONLY) of a pipe(2), we should also allow polling for read, so that the user could listen for a broken pipe on the writing end using uv_read_start() without having to try to write anything to the pipe, or wait until the next write to find out.

Fixes: https://github.com/libuv/libuv/issues/2058

+67 -4

0 comment

7 changed files

fantix

pr closed time in 15 minutes

issue commentmicrosoft/TypeScript

Project References and noEmitOnError

A few more details my usecase here, which I suspect are similar to the OP.

  • Typescript monorepo utilizing composite projects / project references
  • ~55 packages (and slowly growing)
  • Webpack + ts-loader for compilation (running in watch mode)

Here's a few scenarios that have come up in my group:

  1. A developer is working on some new UI in a component, the code is 4 layers deep in project references from the entry point. They want to remove some old UI first, so they delete a bunch of code in the component render. They build some new placeholder UI, then save, hoping to view it in a browser. This fails to compile because of unused imports enforced by the compiler. They now have to to and comment out/remove a bunch of un-used imports to be able to view their code, even though it technically all runs. The same scenario can occur when refactoring a function [We could disable rules for no unused locals/no unused parameters, but we want to catch and warn on this early].
  2. A developer is upgrading a package that's used in a bunch of places across the app. The new version introduces a few typing errors (unknown impact). The developer wants to make sure that basic functionality works before investing in typing changes. Unfortunately, to make this compile, they're going to have to comment out, as any or fix a bunch of places in code to make the entire app compile
  3. A developer is working on a large cross-package refactor. As they start to make changes, they introduce some type errors - however these don't affect the core use-case. They're now unable to test any of their core use-case changes until they've either commented out the "broken" code or addressed the specific type-errors.

Most of these cases are "in-between" states but multiple developers have had their common workflows slowed down by this limitation. We still want these errors to be surfaced/visible (and block CI/production builds). Still the cost of doing multiple re-builds is likely cheaper than an individual dealing with all the potential errors. On the happy path, there won't be any re-builds as everything would compiler error free.

I agree entirely about the opt-in behaviour, I think that the noEmitOnError flag could be utilized here potentially - although the default would have to change for some projects, which could be confusing. (I'd argue it's confusing now since it has no effect)

There's also the question of what .d.ts should be emitted on error, but I imagine that behaviour is already ratified under noEmitOnError handling.

nullxone

comment created time in an hour

issue openedmicrosoft/TypeScript

generics that extend conditional types that use another generic don't worm

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a bug, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:

  • Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  • Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the entire template below. -->

<!-- Please try to reproduce the issue with the latest published version. It may have already been fixed. For npm: typescript@next This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly --> TypeScript Version: 3.7.x-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) --> Search Terms: Conditional types generics Code

interface Foo<T, U extends T extends number? any: any> {}
function foo<T>(bar: Foo<T, number>) {}

Expected behavior: No error, U is any Actual behavior: Error 2344: Type 'number' does not satisfy the constraint 'T extends number? any: any' Playground Link: <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> Writing this on my phone and playground doesn't seem to work on mobile, will post one later Related Issues: <!-- Did you find other bugs that looked similar? --> Maybe #41040 ?

created time in an hour

issue openedlibuv/libuv

linux: regression in uv_fs_sendfile()

Hello everyone,

Sad but true, libuv keeps breaking as my internal tests started failing on Linux at some point. This time, uv_fs_sendfile() appears to be messed up. At first sight, in_offset acts more like an offset for output for some reason which also leads to some kind of weird zero padding at the beginning of a file. Please take a look at the following snippet:

#include <uv.h>
#include <assert.h>

int main() {
    uv_loop_t *loop = uv_default_loop();
    uv_fs_t req;
    uv_buf_t buf = uv_buf_init("0123456789", 10);
    int fd1 = uv_fs_open(loop, &req, "test1.dat", UV_FS_O_RDWR | UV_FS_O_CREAT | UV_FS_O_TRUNC, 0666, 0);
    int fd2 = uv_fs_open(loop, &req, "test2.dat", UV_FS_O_RDWR | UV_FS_O_CREAT | UV_FS_O_TRUNC, 0666, 0);
    assert(fd1 >= 0 && fd2 >= 0);
    assert(uv_fs_write(loop, &req, fd1, &buf, 1, 0, 0) == 10);
    assert(uv_fs_sendfile(loop, &req, fd2, fd1, 8, 1, 0) == 1);
    assert(uv_fs_sendfile(loop, &req, fd2, fd1, 9, 1000, 0) == 1);
    assert(!uv_fs_close(loop, &req, fd1, 0));
    assert(!uv_fs_close(loop, &req, fd2, 0));
    assert(!uv_loop_close(loop));
    return 0;
}

FreeBSD, macOS, i.e. expected behaviour:

$ cc -luv test.c
$ ./a.out
$ hexdump -C test2.dat
00000000  38 39                                             |89|
00000002

Linux:

$ cc -luv test.c
$ ./a.out
a.out: test.c:13: main: Assertion `uv_fs_sendfile(loop, &req, fd2, fd1, 9, 1000, 0) == 1' failed.

$ hexdump -C test2.dat
00000000  00 00 00 00 00 00 00 00  30 31 32 33 34 35 36 37  |........01234567|
00000010  38 39                                             |89|
00000012
  • Version: 1.40
  • Platform: Linux

created time in 2 hours

issue openedmicrosoft/TypeScript

String literal type is always widened when used as a generic type parameter

TypeScript Version: v4.2.0-dev.20201130

Search Terms: widening type parameter

Code:

function fn<T extends 'foo' | 'bar'>(a: T, b: T) {}
fn('foo', 'bar');

Expected behavior: Argument of type '"bar"' is not assignable to parameter of type '"foo"'.. Since 'foo' and 'bar' are different types, it shouldn't be possible for the same type parameter to allow both of them.

Actual behavior: no error, since the arguments' types are widened.

This definitely seems like reasonable behavior without an explicit "extends" clause (this was brought up in #6167):

function fn<T>(a: T, b: T) {}
fn('foo', 'bar'); // I *want* this to resolve to string! only args like (10, 'foo') should break

But this behavior is harder to justify in my first example, since I'm treating the string literal types like enum values; I want them to behave independently as their own types, not widen and act like the same type when they're being matched to the T type parameter.

It might not be so easy to tell the programmer's intention in this case, but it should be clearer here:

function fn2<T extends 'foo' | 'bar'>(a: T, b: T) {}
const foo: 'foo' = 'foo'; // I think the type annotation is redundant here because it's a const declaration
const bar: 'bar' = 'bar';
fn2(foo, bar);

This still doesn't error, which tells me the type is still widening to 'foo' | 'bar' even though the arguments are very explicitly typed as 'foo' and 'bar'. The widening only seems to happen when the arguments are actually different. When I hover over the function call in VS Code (not sure what that view is called), I see two different evaluated type definitions depending on the function call:

  • If I hover over fn2(foo, foo), I get function fn2<"foo">(a: "foo", b: "foo"): void.
  • If I hover over fn2(foo, bar), I get function fn2<"foo" | "bar">(a: "foo" | "bar", b: "foo" | "bar"): void.

This seems to indicate that the type system is explicitly making a widening decision when it "notices" that the literal type doesn't fit, which I don't really want it to do.

#6196 seems to be the closest anyone got to addressing the concerns raised in #6167. This seems to have been enough to close out #6167, but unfortunately it only strictifies conditional logic, not this type parameter spookiness.

Here's another (slightly closer to real-world) example, similar to what I was building when I came across this issue. In this example, it's trickier (i.e. not constant-time) to determine the second argument's type based on the first argument at runtime (where, obviously, in my first example, there's no reason to write a function that takes in the exact same string two times):

type Key = "foo" | "bar";
type Haystack<T> = Array<number | T>;

function fn<T extends Key>(a: T, b: Haystack<T>) {}

fn("foo", [1, 2, 3, 4, "foo"]);
fn("foo", [1, 2, 3, 4, "bar"]); // should error
fn("bar", [1, 2, 3, 4, "foo"]); // should error
fn("bar", [1, 2, 3, 4, "bar"]);

Workarounds:

One option is to call the function with an explicitly-bound T:

function fn<T extends 'foo' | 'bar'>(a: T, b: T) {}
fn<'foo'>('foo', 'bar'); // Argument of type '"bar"' is not assignable to parameter of type '"foo"'.

This also works with typeof, which (as far as I can tell) should be available in every case where the type-checker would be able to determine that there's an error anyway:

function fn<T extends 'foo' | 'bar'>(a: T, b: T) {}
const foo = 'foo';
const bar = 'bar';
fn<typeof foo>(foo, bar); // Argument of type '"bar"' is not assignable to parameter of type '"foo"'.

This doesn't feel like a general-purpose solution, though, because the T parameter might not be so easily accessible:

type Key = "foo" | "bar";
type Haystack<T> = Array<number | T>;

function fn<T extends Key>(a: Haystack<T>, b: Haystack<T>) {}

fn([1, 2, 3, 4, 'foo'], [5, 6, 7, 8, 'bar']);
// fn<typeof ????>(...)
// it's trickier (but still possible) to come up with an example like this that doesn't use array literals.

Here's another workaround I found, and honestly I don't understand why this works:

function fn<T extends 'foo' | 'bar', E extends T>(a: T, b: E) {}
fn('foo', 'bar'); // Argument of type '"bar"' is not assignable to parameter of type '"foo"'.

The fact that introducing a second type parameter that's identical to the first one causes the type not to be widened is really surprising to me. Even if the opinion of TS is that my initial code example shouldn't result in an error, it seems like a bug that this snippet behaves differently.

Playground Link:

https://www.typescriptlang.org/play?ts=4.2.0-dev.20201130#code/GYVwdgxgLglg9mABMMAeAKogpgDylsAEwGdEByYOOMxAH3ICMBDAJzID4AKJgLkXQA0iBn3QBKRAG8AvgCgUnClTJCyzNmIDcQA

Related Issues:

#6167: this issue is described in the "Widening" section. this issue was closed by a few PRs that address related behavior, but which don't actually fix this particular problem. #5300, #5517 #6196, which seems to be the closest anyone got to addressing this, but which doesn't

created time in 2 hours

Pull request review commentmicrosoft/TypeScript

Support 'typeof class' types

+// @strict: true
+// @declaration: true
+
+type TC1 = typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+
+declare let C1: TC1;
+C1.n;
+let c1 = new C1('hello');
+c1.s;
+
+declare let C2: typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C2.n;
+let c2 = new C2('hello');
+c2.s;
+
+declare let C3: typeof class extends Error {
+    constructor(s: string);
+    static n: number;
+}
+C3.n;
+let c3 = new C3('hello');
+c3.message;
+
+declare let C4: typeof abstract class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C4.n;
+let c4 = new C4('hello');  // Error
+
+declare let C5: typeof class<T> {
+    constructor(x: T);
+    x: T;
+}
+
+let c51 = new C5('hello');
+c51.x;
+let c52 = new C5(42);
+c52.x;
+
+type BoxFactory<T> = typeof class Box {
+    static default: T;
+    constructor(value?: T);
+    value: T;
+}
+
+declare let StringBox: BoxFactory<string>;
+StringBox.default;
+let sb = new StringBox('hello');
+sb.value;
+
+declare let NumberBox: BoxFactory<number>;
+NumberBox.default;
+let nb = new NumberBox(42);
+nb.value;
+
+declare const sb1: InstanceType<BoxFactory<string>>;
+sb1.value;
+
+declare const nb1: InstanceType<BoxFactory<number>>;
+nb1.value;
+
+function Printable1<T extends new (...args: any[]) => object>(Base: T) {
+    return class extends Base {
+        static foo: string;
+        print() {}
+    }
+}
+
+declare function Printable2<T extends new (...args: any[]) => object>(Base: T): typeof class extends Base {

To be clear: T is the constructor type, Base is the constructor value.

ahejlsberg

comment created time in 2 hours

issue openedmicrosoft/TypeScript

Cannot use bigint with any in certain arithmetic expressions

TypeScript Version: 4.2.0-dev.20201130

Search Terms: is:issue bigint

Code

var x: any, y: bigint
-x + y
++x + y
x++ + y
~x + y
x - x + y
x * x + y

Expected behavior:

The code should compile without errors, because x could be a bigint.

Actual behavior:

Each of the expressions fails to typecheck: error TS2365: Operator '+' cannot be applied to types 'number' and 'bigint'..

Playground Link: link

Related Issues: none.

created time in 2 hours

issue commentmicrosoft/TypeScript

Nullish operator doesn't narrowing void type

But why it works on ||?

Jack-Works

comment created time in 2 hours

startedSamVerschueren/tsd-typescript

started time in 2 hours

issue commentmicrosoft/TypeScript

'bigint' is not comparable to 'number' with loose equality

The interesting thing about comparing numbers with bigints in JavaScript is that it is not implemented by coercing both operands to numbers, nor is it implemented by coercing both arguments to bigints. Instead, the exact real values are compared. Here are some examples:

These values are different:

> 10n**50n == 10**50
false

But they become equal when coerced to numbers:

> Number(10n**50n) == Number(10**50)
true

These values can be compared:

> 1n == 1.5
false

But cannot be coerced to bigints:

> BigInt(1n) == BigInt(1.5)
Uncaught:
RangeError: The number 1.5 cannot be converted to a BigInt because it is not an integer

Currently, it is not possible to get this comparison semantics in TypeScript without using type assertions. I agree that == operator shouldn't have the same strict type checking rules as === operator, as the use of the former signals the intent that the operands may be of different types.

2A5F

comment created time in 2 hours

PR opened libuv/libuv

unix: re-allow WRONLY fd in uv_read_start

For the writing end (O_WRONLY) of a pipe(2), we should also allow polling for read, so that the user could listen for a broken pipe on the writing end using uv_read_start() without having to try to write anything to the pipe, or wait until the next write to find out.

Fixes: https://github.com/libuv/libuv/issues/2058

+59 -3

0 comment

4 changed files

pr created time in 3 hours

issue commentmicrosoft/TypeScript

Mapped tuples types iterates over all properties

@ahejlsberg

We should probably also do it for homomorphic mapped types with a keyof T where T is non-generic type.

And maybe also where T is a generic type constrained to an array/tuple type like T extends Array<X>?

lemoinem

comment created time in 3 hours

push eventtc39/proposals

Long Ho

commit sha 074cc08fde9ff170f04df2e7630f9d7ce825c907

add `Intl.bestAvailableLocale` proposal to stage 0 @sffc @zbraniecki

view details

Long Ho

commit sha a1b3be7f152d3984896bb6624c39333708aa365a

Update stage-0-proposals.md

view details

Septs

commit sha 6f77ae98795e4841c91d678ac80ec59b9927ffcb

Merge pull request #329 from longlho/patch-1 add `Intl.bestAvailableLocale` proposal to stage 0

view details

push time in 3 hours

PR merged tc39/proposals

add `Intl.bestAvailableLocale` proposal to stage 0

@sffc @zbraniecki

+2 -0

0 comment

1 changed file

longlho

pr closed time in 3 hours

Pull request review commentmicrosoft/TypeScript

Support 'typeof class' types

+// @strict: true
+// @declaration: true
+
+type TC1 = typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+
+declare let C1: TC1;
+C1.n;
+let c1 = new C1('hello');
+c1.s;
+
+declare let C2: typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C2.n;
+let c2 = new C2('hello');
+c2.s;
+
+declare let C3: typeof class extends Error {
+    constructor(s: string);
+    static n: number;
+}
+C3.n;
+let c3 = new C3('hello');
+c3.message;
+
+declare let C4: typeof abstract class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C4.n;
+let c4 = new C4('hello');  // Error
+
+declare let C5: typeof class<T> {
+    constructor(x: T);
+    x: T;
+}
+
+let c51 = new C5('hello');
+c51.x;
+let c52 = new C5(42);
+c52.x;
+
+type BoxFactory<T> = typeof class Box {
+    static default: T;
+    constructor(value?: T);
+    value: T;
+}
+
+declare let StringBox: BoxFactory<string>;
+StringBox.default;
+let sb = new StringBox('hello');
+sb.value;
+
+declare let NumberBox: BoxFactory<number>;
+NumberBox.default;
+let nb = new NumberBox(42);
+nb.value;
+
+declare const sb1: InstanceType<BoxFactory<string>>;
+sb1.value;
+
+declare const nb1: InstanceType<BoxFactory<number>>;
+nb1.value;
+
+function Printable1<T extends new (...args: any[]) => object>(Base: T) {
+    return class extends Base {
+        static foo: string;
+        print() {}
+    }
+}
+
+declare function Printable2<T extends new (...args: any[]) => object>(Base: T): typeof class extends Base {

Oh sorry, T is the constructor type, Base is the instance type.

ahejlsberg

comment created time in 3 hours

push eventtc39/proposals

Frank Yung-Fong Tang

commit sha afbf358db1812e6e6d03f2d073acabef074e6191

add eradisplay @sffc @Louis-Aime

view details

Frank Yung-Fong Tang

commit sha 37d90184fc6b67ac06ce4fc4622d05c57163925c

Update ecma402/stage-0-proposals.md Co-authored-by: Septs <github@septs.pw>

view details

Frank Yung-Fong Tang

commit sha 28cd98965ee26b43b3ce98243e8b0fbb3335bad8

Merge pull request #328 from tc39/FrankYFTang-patch-3 add eradisplay to stage 0 of ECMA402

view details

push time in 3 hours

delete branch tc39/proposals

delete branch : FrankYFTang-patch-3

delete time in 3 hours

PR merged tc39/proposals

add eradisplay to stage 0 of ECMA402

@sffc @Louis-Aime @gibson042 @leobalter @zbraniecki

+2 -0

0 comment

1 changed file

FrankYFTang

pr closed time in 3 hours

push eventtc39/proposals

Frank Yung-Fong Tang

commit sha 37d90184fc6b67ac06ce4fc4622d05c57163925c

Update ecma402/stage-0-proposals.md Co-authored-by: Septs <github@septs.pw>

view details

push time in 3 hours

Pull request review commentmicrosoft/TypeScript

Support 'typeof class' types

+// @strict: true
+// @declaration: true
+
+type TC1 = typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+
+declare let C1: TC1;
+C1.n;
+let c1 = new C1('hello');
+c1.s;
+
+declare let C2: typeof class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C2.n;
+let c2 = new C2('hello');
+c2.s;
+
+declare let C3: typeof class extends Error {
+    constructor(s: string);
+    static n: number;
+}
+C3.n;
+let c3 = new C3('hello');
+c3.message;
+
+declare let C4: typeof abstract class {
+    constructor(s: string);
+    static n: number;
+    s: string;
+}
+C4.n;
+let c4 = new C4('hello');  // Error
+
+declare let C5: typeof class<T> {
+    constructor(x: T);
+    x: T;
+}
+
+let c51 = new C5('hello');
+c51.x;
+let c52 = new C5(42);
+c52.x;
+
+type BoxFactory<T> = typeof class Box {
+    static default: T;
+    constructor(value?: T);
+    value: T;
+}
+
+declare let StringBox: BoxFactory<string>;
+StringBox.default;
+let sb = new StringBox('hello');
+sb.value;
+
+declare let NumberBox: BoxFactory<number>;
+NumberBox.default;
+let nb = new NumberBox(42);
+nb.value;
+
+declare const sb1: InstanceType<BoxFactory<string>>;
+sb1.value;
+
+declare const nb1: InstanceType<BoxFactory<number>>;
+nb1.value;
+
+function Printable1<T extends new (...args: any[]) => object>(Base: T) {
+    return class extends Base {
+        static foo: string;
+        print() {}
+    }
+}
+
+declare function Printable2<T extends new (...args: any[]) => object>(Base: T): typeof class extends Base {

Is there a difference between typeof class extends Base { and typeof class extends T { here?

ahejlsberg

comment created time in 3 hours

issue commentmicrosoft/TypeScript

Pipe/flow/chain type support

My vote would be to describe such types using something similar to the mathematical notation where n is used to describe a series, which is then defined by relationships between members of that series.

function pipe<T[n]>(...operators: Array<OperatorFunction<T[n], T[n+1]>>): Observable<T[n]> {
...
}
andykais

comment created time in 3 hours

PR opened tc39/proposals

add `Intl.bestAvailableLocale` proposal to stage 0

@sffc @zbraniecki

+2 -0

0 comment

1 changed file

pr created time in 3 hours

issue commentmicrosoft/TypeScript

Project References and noEmitOnError

tsc -b is intended to build whole solution/ all projects you specify.. it also does not watch or keep track of anything except time stamps specified by input and output.. this results in fast check to decide if given project needs to be rebuilt..
The theory behind not building project if referenced project has errors, is that if there are errors in dependencies likely, there will be errors in the project itself so you are just increasing number of errors to report (emitting without reporting errors seems like it would be incorrect to do either) and resulting output is potentially not consumable either since it has errors that tsc detected. It means two things happen if we emit irrespective of errors: You are building many more projects which could be huge perf factor for big solutions. And it would probably be very difficult for user to diagnose the issues.

While there are some errors that could only affect in local projects, we have not yet drilled into what it means from build stand point for such errors to be present so we treat all errors same. Other issue with this approach is that not every project built by tsc -b needs to write tsbuildinfo, because only referenced projects have composite mandatory. The outer project might not have incremental set and then it poses another issue with how to detect easily if output stamps are upto date because there is not tsbuildinfo to read to see if this was emitted with or without errors and if project needs to be reconstructed to report errors

So even if this feature is enabled we would only enable them for project set with incremental flag. But its still not clear what the right approach is.. Is it ignoring specific errors, should those be configured by user or could it be any errors. Definitely should be opt in feature as well to avoid having every tsc -b user pay penalty for these extra builds..

tsc -p builds only the project and not its dependencies, It also doesnt check timestamps so it has its limitations as in any change to dependency would not be picked until dependency project is rebuilt.

We need more feedback on why this makes sense and what kind of scenarios people are looking when they want their referenced projects to be built if there are errors to come up with proposal on what this request is.

nullxone

comment created time in 4 hours

Pull request review commenttc39/proposals

add eradisplay to stage 0 of ECMA402

 Stage 0 proposals are either | -------------------------------------------------------------------- | ---------------- | ------------------ | | [Fix 9.2.3 LookupMatcher algorithm][]                                | Rafael Xavier    | Rafael Xavier      | | [`Intl.NumberFormat` `round` option][intl.numberformat round option] | Rafael Xavier    | Rafael Xavier      |+| [eraDisplay option for Intl.DateTimeFormat][eradisplay]              | Louis-Aime       | Louis-Aime         |
| [eraDisplay option for `Intl.DateTimeFormat`][eradisplay]              | Louis-Aime       | Louis-Aime         |
FrankYFTang

comment created time in 4 hours

PR opened tc39/proposals

add eradisplay to stage 0 of ECMA402

@sffc @Louis-Aime @gibson042 @leobalter @zbraniecki

+2 -0

0 comment

1 changed file

pr created time in 4 hours

create barnchtc39/proposals

branch : FrankYFTang-patch-3

created branch time in 4 hours

issue commentmicrosoft/TypeScript

Project References and noEmitOnError

Having noEmitOnError is also quite helpful for package upgrades & big refactors. Sometimes it's necessary to check behavioural semantics on a new package/changeset while working through type errors. (This is especially important if @types has a bug or is missing a changed type)

A couple questions to the typescript team (@RyanCavanaugh? Sorry for the mention)

  1. Is this proposal something that's inline with the product roadmap?
  2. Would including error information in .tsbuildinfo be sufficient to make this work, or are there other considerations
  3. Beyond prioritization/resourcing, are there any known technical hurdles that would block adding this support?

Lack of this support is hurting developer productivity on our project. Ultimately we need to find a solution & moving off project references is a viable option if there's no chance that this would be supportable in the future. I expect that other large typescript projects would feel similar pain.

nullxone

comment created time in 4 hours

push eventmicrosoft/TypeScript

Keen Yee Liau

commit sha cf4df4e472ec34cadc30052f2af0c2fc6c42b843

fix(41736): tsserver should not crash if external file does not exist (#41737) If a file does not exist, `projectService.getOrCreateScriptInfoNotOpenedByClient()` will return `undefined`, but tsserver does not handle this case. Fix https://github.com/microsoft/TypeScript/issues/41736

view details

push time in 4 hours

PR merged microsoft/TypeScript

Reviewers
fix(41736): tsserver should not crash if external file does not exist For Uncommitted Bug

If a file does not exist, projectService.getOrCreateScriptInfoNotOpenedByClient() will return undefined, but tsserver does not handle this case.

<!-- Thank you for submitting a pull request!

Please verify that:

  • [x] There is an associated issue in the Backlog milestone (required)
  • [x] Code is up-to-date with the master branch
  • [x] You've successfully run gulp runtests locally
  • [ ] There are new or updated unit tests validating the change

Refer to CONTRIBUTING.MD for more details. https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md -->

Fixes #41736

+41 -2

1 comment

2 changed files

kyliau

pr closed time in 4 hours

more