profile
viewpoint
Nathan Shively-Sanders sandersn Microsoft Seattle @sanders_n on twitter I work on the TypeScript compiler, mostly JS support and Definitely Typed.

sandersn/downlevel-dts 113

Convert a new d.ts to one that works with older versions of Typescript

DefinitelyTyped/dts-critic 37

Checks a new dts against the JavaScript sources and tells you what problems it has

sandersn/fing 35

Fing: F# API Search

sandersn/dialect 5

Code for "A Statistical Method For Dialectometry"

DefinitelyTyped/types-publisher-watchdog 3

Report how long DefinitelyTyped's types-publisher takes to publish packages to npm

sandersn/dt-package-tester 3

Install @types packages and run their tests from Definitely Typed

sandersn/elements-of-ai 3

Example implementations from Elements of Artificial Intelligence by Steven Tanimoto

DefinitelyTyped/dt-retag 1

This repo has moved:

sandersn/dt-perf 1

Scripts for analysing Definitely Typed performance on recent versions of Typescript

issue commentmicrosoft/TypeScript

Suggestion: allow get/set accessors to be of different types

@AGluk, this issue needs to be reopened.

irakliy81

comment created time in an hour

create barnchmicrosoft/TypeScript

branch : fix41453

created branch time in an hour

issue commentmicrosoft/TypeScript

Suggestion: Array.prototype.sort - remove the need for compareFn to handle undefined values

Not sure if this is classed as a bug fix or a suggestion, so out of caution I have marked it as a suggestion. If this gets approved as an issue then I will open a PR with a fix!

Brookke

comment created time in 6 hours

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

The only thing you would change is swapping out the Decorators used.

Exactly, and that means there's a static dependency. What if I'm switching from database A to database B, and, for a transitional period, I need to persist to both databases? Or may be I need to use both databases for some reason?

With external schema definition there's no coupling at all.

I think we just disagree on the level of intrusion to the Domain that is OK to have

Yeah, it seems so. So let's agree to disagree here. :-)

boris-kolar

comment created time in 8 hours

issue commentmicrosoft/TypeScript

error TS2554: Expected 2-3 arguments, but got 1

Nov 2020, still

shamhub

comment created time in 9 hours

pull request commentmicrosoft/TypeScript

Template literal types and mapped type 'as' clauses

type Union = "A" | "B" | "C";
type Y<U extends string, T extends string = U> = U extends string ? T extends U ? T : `${U},${T}` : never
type TEST2 = Y<Union>

Does exactly what you want though :)~

thanks for your response this type will only give me subset with 1 or 2 child; but I want any subset of union including 3 member and more for bigger unions

ahejlsberg

comment created time in 10 hours

issue commentmicrosoft/TypeScript

Typescript 3.8.3 : Sharp notation for private method must be alloweded

Is this issue being addressed in the current roadmap? If not, has this issue been triaged at least? Please give us an update of some sorts. Thanks

Binau

comment created time in 10 hours

issue commentmicrosoft/TypeScript

Support `.mjs` output

Feels like commonjs is the IE of node.

I want to output my code to support commonjs and modules, while preserving the directory hierarchy. Think:

import {} from 'rxjs'; 
import {} from 'rxjs/operators';

To do this I need the following directory structure to exist inside node_modules

/node_modules
  /my-example-package
    /foo
      foo.cjs
      foo.mjs
      foo.d.ts
    index.cjs
    inde.mjs
    index.d.ts
    package.json

Where the package.json looks like

{
  "name": "my-example-package",
  "version": "1.0.0",
  "types": "./index.d.ts",
  "main": "./index.cjs",
  "module": "./index.mjs",
  "require": "./index.cjs",
  "exports": {
    ".": {
      "module": "./index.mjs",
      "require": "./index.cjs"
    },
    "./foo": {
      "module": "./foo/index.mjs",
      "require": "./foo.index.cjs"
    }
  }
}

In the end, I would like consumers to be able to import my package via my-example-package or my-example-package/foo. I intend to have several top level folders for different purposes.

As of now TypeScript does not allow the transformation of the import statements of files to automatically include .js. TypeScript also won't compile if you add .mjs as an import extension so you can't even emit files and post process them yourself with shell scripts.

demurgos

comment created time in 15 hours

issue commentmicrosoft/TypeScript

Option resolveJsonModule doesn't work without esModuleInterop

Although I added moduleResolution: node, the error was still there. After a VS restart it got 'fixed'

ikokostya

comment created time in 16 hours

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

Sure, but that approach does not really abstract domain from infrastructure

I'm not sure what you mean by this. I assume its the way your thinking this is implemented. My infrastructure layer sits outside of the domain layer. The purpose of Decorators (in this case) is to not introduce infrastructure into it.

Ideally, one could even switch between different ORMs without changing a single line in domain entities code.

The only thing you would change is swapping out the Decorators used.

boris-kolar

comment created time in 16 hours

issue commentmicrosoft/TypeScript

skipLibCheck and exclude do not work under monorepos project

Same issue here. It takes ages to load all the node_modules d.ts files.

WeijieZhu0204

comment created time in 16 hours

issue openedmicrosoft/TypeScript

Type inference fails

<!-- 🚨 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: 4.2.0-dev.20201127

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

  • typescript type inference
  • typescript type not inferred correctly
  • typescript mapped types

Code

interface INodeIO<T = any> {
    value: T;
}

type IODefinition = Record<string, INodeIO>;
type IODefinitionValues<D extends IODefinition> = {
    [K in keyof D]: D[K] extends INodeIO<infer T> ? T : never;
};
type CalcFunc<I extends IODefinition, O extends IODefinition> = (
    inputs: IODefinitionValues<I>
) => IODefinitionValues<O>;

type NodeDefinition<I extends IODefinition, O extends IODefinition> = {
    setup(): { inputs: I; outputs: O };
    calculate?: CalcFunc<I, O>;
};

function defineNode<I extends IODefinition, O extends IODefinition>(def: NodeDefinition<I, O>) {
    return def; // placeholder
}

// T1 is correctly identified as
// T1 = { hello: number; }
type T1 = IODefinitionValues<{ hello: { value: number } }>;

// T2 is identified as (inputs: IODefinitionValues<{ test: { value: number; };}>) => IODefinitionValues<{ ret: { value: boolean; }; }>
type T2 = CalcFunc<{ test: { value: number } }, { ret: { value: boolean } }>;


// This works as expected, Intellisense is working and I get type errors when using the wrong type
const calcFuncTest: T2 = (def) => ({ ret: Boolean(def.test) });
calcFuncTest({ test: 3 });

defineNode({
    setup() {
        return {
            inputs: {
                a: { value: 3 },
                b: { value: "bar" }
            },
            outputs: {
                c: { value: false },
                d: { value: "foo" }
            }
        };
    },
    calculate(inputs) {
        return {
            c: inputs.v, // (1)
            d: inputs.a, // (2)
        };
    }
});

Expected behavior:

  • (1) should give an error, since inputs.v does not exist
  • (2) should give an error, since inputs.a is a number, while d is a string

Actual behavior: The code above compiles without errors. Also, Intellisense is not working at the calculate function inside defineNode.

Playground Link: <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> Link

Related Issues: <!-- Did you find other bugs that looked similar? -->

created time in 17 hours

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

Decorators are part of what's called Aspect-oriented programming, and fundamentally abstract away the database in a declarative way.

Sure, but that approach does not really abstract domain from infrastructure. The idea of DDD is domain modeling first, with persistence layer completely being out of scope of domain level - even the fact that a relational database is being used for persistence should be outside the scope. Ideally, one could even switch between different ORMs without changing domain entities.

I can agree that AOP approach has its benefits, but I believe the choice should be made by programmer, and not enforced by language design.

in the schema you have to specify a runtime type of a property - and there is no compile time guarantee it matches the actual class property definition.

Those types are mappings to SQL types, and, of course, there's no real compile time guarantee for that (and I doubt it's even possible to do without dependent types). But it tries to do what's possible: queries in find* methods are (moslty) type-safe, take a look at Query<T> for example.

I just wanted to know more use cases beyond decorators where removing the private modifier would be beneficial.

I believe it's a good idea to think of a type-safe Automapper as a general case. All the specific cases like ORM, serialization, etc are basically mappers with extra steps.

boris-kolar

comment created time in 17 hours

fork ifiokjr/downlevel-dts

Convert a new d.ts to one that works with older versions of Typescript

fork in 17 hours

pull request commentmicrosoft/TypeScript

Expunge the concept of well-known symbols from the checker

FWIW, this PR would also probably fix https://github.com/immerjs/immer/issues/710.

weswigham

comment created time in 17 hours

issue openedmicrosoft/TypeScript

another way of noUncheckedIndexedAccess

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

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

  • Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  • Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

Suggestion

tsconfig: noUncheckedIndexedAccess is a good new feature, but whole project level setting is too coarse-grained to use.

traditional { [index :number] :undefined | T } could control that in api level. but not like noUncheckedIndexedAccess, it makes arr[0] = undefined valid which is not intended.

I wait the feature so long, but when I open noUncheckedIndexedAccess, there are too many too many too many errors, which cause trouble far more than help.

so in fact, we need a feature that makes T-only when writing, and T | undefined when reading.

Use Cases

<!-- What do you want to use this for? What shortcomings exist with current approaches? -->

Examples

<!-- Show how this would be used and what the behavior would be -->

maybe something like:

type MyArray<T> = {
    undefined [index :number] :T
}

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [x] This feature would agree with the rest of TypeScript's Design Goals.

created time in 19 hours

issue commentmicrosoft/TypeScript

Typescript: TSServer: Code Fixes: Import missing imports with a symlinked node_modules folder is very slow

@sheetalkamat I setup a small repro illustrating the difference in VSCode between Yarn & PNPM here: https://github.com/walkerburgin/tsserver-pnpm-repro

Here are the suggestions when installing dependencies with Yarn: image

And with PNPM: image

If you set "preserveSymlinks": true, PNPM matches Yarn's behavior in VSCode but it doesn't actually compile for the reasons I described above. I'm not sure how to reproduce the root performance issue itself in a small or self contained way.

frederikdekegel

comment created time in 19 hours

issue commentmicrosoft/TypeScript

Optional chaining union type with interfaces

I was thinking the same that @mdbetancourt posted but with the first example.

interface Common {
    name: string
    age: number
}

interface A extends Common{
    address: string
}

interface B extends Common{
    city: string
}

interface C extends A {
  city: number;
}

type MyType = A | B

const func = (arg: MyType) => {
    const res = 'city' in arg? arg.city : undefined;
}

const c: C = {
    name: 'Bob',
    age: 50,
    address: 'Fake street',
    city: 200
};

func(c);

res here can be string | undefined, but in runtime it will receive a number. So it seems weird that not being able to do arg.city is because the type might be wrong, considering that it would be equivalent to 'city' in arg? arg.city : undefined.

deser

comment created time in 21 hours

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

@UTGuy , right, my comment was about defining schema via EntitySchema, without decorators (in response to @kbaryshnikov). I agree that with decorators it has desired type safety, except for private. I just wanted to know more use cases beyond decorators where removing the private modifier would be beneficial.

boris-kolar

comment created time in a day

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

@amakhrov

Unless I missed the point, in the schema you have to specify a runtime type of a property - and there is no compile time guarantee it matches the actual class property definition.

Mikro-orm IS type-safe. The first case would be using an interface for both the Entity Schema and then using the same interface on the Domain model. The second case is using Decorators on the Domain model. In both cases you would use the Domain model in the query, as Mikro-orm will make the query type-safe based on that.

boris-kolar

comment created time in a day

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

@kbaryshnikov good point. Data mapper is a good example.

One could argue that this particular implementation (mikro-orm) is not really type safe anyway. Unless I missed the point, in the schema you have to specify a runtime type of a property - and there is no compile time guarantee it matches the actual class property definition.

I would say such use case would benefit from a full-featured reflection api in Typescript (which is currently only achievable with decorators and not as an independent first class concept)

boris-kolar

comment created time in a day

issue commentmicrosoft/TypeScript

TypeScript 4.2 Iteration Plan

Is there a way to suggest issues/tasks for a TS release?

DanielRosenwasser

comment created time in a day

issue commentmicrosoft/TypeScript

Removing "private" modifier from types

I agree with most of your post, but, I'd like to point out a few things...

all properties need to be public, even when it's undesirable

In the context of Mikro-orm and Decorators this is not the case... properties can be private. The schema is discovered through decorators instead of declared up front.

And, while mikro-orm supports decorators, decorator-based schema definition is considered a bad practice because, again, it mixes pure domain logic with details of infrastructure implementation

I disagree... Decorators are part of what's called Aspect-oriented programming, and fundamentally abstract away the database in a declarative way. AOP can be seen not just in Typescript/Javascript, but it C# as well (and I'm sure many other languages).

boris-kolar

comment created time in a day

issue commentmicrosoft/TypeScript

Add support for nested generics

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

janaszer

comment created time in a day

issue closedmicrosoft/TypeScript

Add support for nested generics

Suggestion

Please add support for deeply nested generics.

Use Cases

This is mostly useful for React development. We can have higer order components that might take generic class and return generic class. However deeply nested generics are inferred as unknown type.

Also connect from react-redux shows the same behaviour.

Examples

// Imagine I have generic component like this:
class Comp<T> extends React.Component<{ data: T, width: number}> {}
// and this is my generic function - it takes component and returns component (with one property less)
function WithWidth<T extends { width: number }>(component: React.ComponentType<T>): React.ComponentType<Omit<T, 'width'>>{
    ...
}

// here I want to create component based on Comp, but with one property bounded
const CompWithWidth = WithWidth(Comp);

In that example CompWithWidth has type:

React.ComponentType<Pick<{
    data: unknown;
    width: number;
}, "data">>

so data is no longer generic parameter. It is unknown from now on.

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [x] This feature would agree with the rest of TypeScript's Design Goals.

closed time in a day

janaszer

issue commentmicrosoft/TypeScript

TS 4.1.2 Cannot find name 'FieldValue' (solved in 4.2)

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

sk-

comment created time in a day

issue closedmicrosoft/TypeScript

TS 4.1.2 Cannot find name 'FieldValue' (solved in 4.2)

In TS 4.1.2, depending on how you import FieldValue (a firestore type), the class won't be defined. This affects only 4.1.2, as it seems to have been fixed in 4.2.

<!-- 🚨 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: 4.1.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) --> Search Terms: FieldValue undefined cannot

Code

const {FieldValue} = require('firebase-admin').firestore;
console.info(FieldValue);

Expected behavior: No error is raised.

Actual behavior:

 Cannot find name 'FieldValue'.

Note that the code correctly prints out:

[class FieldValue]

Note also that the following code compiles without errors:

const admin = require('firebase-admin');
const {FieldValue} = admin.firestore;
console.info(FieldValue);

const {equal} = require('assert').strict
console.info(equal);

Playground Link: <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

Related Issues: <!-- Did you find other bugs that looked similar? -->

closed time in a day

sk-

issue commentmicrosoft/TypeScript-Node-Starter

Visual Studio code does not recognize jest ts

If you don't want to add the tests folder to the tsconfig.json - why would you? - then you can get rid of the annoying problem messages in VS Code by adding this to the top of the folder

import { describe, test, expect } from '@jest/globals';

And any others you might need. Still hard to understand why @types/jest are not recognised.

panitaxx

comment created time in a day

pull request commentmicrosoft/TypeScript-Node-Starter

start-dev launch option (ts-node-dev)

why this is not merged ? this is a must have when you are working on a project

GrayStrider

comment created time in a day

more