profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/DanielRosenwasser/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Daniel Rosenwasser DanielRosenwasser @Microsoft Seattle, WA https://twitter.com/drosenwasser Program Manager of TypeScript

DanielRosenwasser/babel-typescript-sample 20

A sample setup using Babel CLI to build TypeScript code, and using TypeScript for type-checking.

DanielRosenwasser/DefinitelyTyped 1

The repository for high quality TypeScript type definitions.

DanielRosenwasser/ace 0

Build Cordova apps with true native UI

DanielRosenwasser/angular2-data-table 0

✨ A feature-rich yet lightweight data-table crafted for Angular2!

DanielRosenwasser/ant-design-icons 0

⭐ Ant Design SVG Icons

DanielRosenwasser/apollo-server 0

🌍 GraphQL server for Express, Connect, Hapi, Koa and more

DanielRosenwasser/awesome-js-tools 0

An awesome list for JS tools

DanielRosenwasser/axe-core 0

Accessibility engine for automated Web UI testing

issue commentmicrosoft/TypeScript

Design Meeting Notes, 9/22/2021

Sorry @andrewbranch, that's what the notes were meant to reflect, but the convo was happening a bit too fast.

I think the analogy was fine. Usually the idiom "it's not rocket science" implies "this is simple, so nobody should get overwhelmed by it" whereas this is something we don't think is simple, and thus can make no guarantees about whether anyone will be overwhelmed by it 😅

DanielRosenwasser

comment created time in 15 hours

issue commentmicrosoft/TypeScript

Design Meeting Notes, 9/22/2021

I think given the fact that TypeScript has to lay its own .d.ts resolution on top of other resolution means that was an inevitability anyway.

But the complexity is more about supporting users, not supporting the logic ourselves. We can barely keep the whole thing in our heads, but we've spent years thinking about it, so we think there's a very small chance that a user would figure out the correct setup quickly on their own.

DanielRosenwasser

comment created time in 16 hours

pull request commentmicrosoft/TypeScript

Default tsc --init to es2016

I would hope that dom isn't excluded as a result of target - that would be a confusing upgrade step. 😬

orta

comment created time in 16 hours

pull request commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

Looks like there's a few conflicts that need to be resolved.

ahejlsberg

comment created time in 16 hours

issue openedmicrosoft/TypeScript

Design Meeting Notes, 9/22/2021

Binding Pattern Breaking Changes

https://github.com/microsoft/TypeScript/issues/45846#issuecomment-921371236 https://github.com/microsoft/TypeScript/pull/46009

  • Motivation

    declare function g<T>(): T;
    
    // Type is { x: any, y: any, g: any }
    // which is kind of dumb.
    const { x, y, z } = g();
    
  • Other more complex issues.

  • Why?

    • Best thing we can imagine is left-to-right completions for

      const { x, y, z } = { /*|*/ }
      //                      ^
      // We expect completions for x, y, z.
      
  • Current proposal is to disable for object binding patterns, but re-enable contextual typing from array binding patterns.

  • We still don't fully understand the inferences - probably best to do that.

  • When we started doing implied types from binding patterns, we didn't have types apart from any - now have never and unknown.

  • Let's do a full revert and think through this a bit more.

Node ESM Support

https://github.com/microsoft/TypeScript/pull/44501 https://github.com/weswigham/TypeScript/pull/67 https://github.com/weswigham/TypeScript/pull/68

  • New resolution modes: node12 and nodenext

  • CJS and ESM files can resolve files via different paths based on the syntax and containing file.

    // Always follow CJS resolution
    import foo = require("foo")
    
    // Dynamic import - always follow ESM resolution
    const a = import("foo");
    
    // Always depends on the **containing file**!
    import * as a from "foo";
    
  • This is "solved" albeit complicated, but what is not solved is...

  • Import type syntax:

    type Foo = import("foo").Foo;
    
    • Can't disallow in CJS files because of existing CJS .d.ts files.
  • So how do you differentiate between "this should resolve as ESM vs CJS"?

    • Don't have any other syntax for inline type import syntax.
  • Could have a different conditions passed into import(...) types.

    • Like in an import assertion: import("foo", { /*conditions*/ })
  • Why does this matter?

    • Different resolution will fetch you a different file
      • Even if both are to the same package path.
      • e.g. import "lodash" and require("lodash") can fetch TWO DIFFERENT FILES in node_modules/lodash/.
    • https://nodejs.org/api/packages.html#packages_conditional_exports
  • Technically the MVP doesn't need to include this...but it will likely be an issue.

  • If you need to reference a type in ESM, either in .d.ts emit or by-hand, can you just write

    import "esm-file";
    
    • No, you can't :(
  • Can you lean on import() types always getting inferred from containing context?

    • Yes, you have to for compat, but you can't model a CJS file that actually import()s an ESM.
  • Import assertions affecting module resolution?

    • Seems like a no-no, but might need to use sibling conditions as a way to bypass that.

      type Foo = import("foo", { assert: { }, resolver: "esm" });
      
  • Heavy regret of not introducing require() types; now you need a "real import type" type.

  • Whole thing is such a 🤬😫😢😭

  • What if we just didn't let you write import in a non-module file?

    • Force users to write require() in CJS
    • Goes against a lot of expectations.
    • Isn't that what people want to write though?
    • What is the guidance? Users should use module: node12, but as far as they're concerned they're still doing CJS.
  • If our heads are spinning from this, users' will too.

    • A lot of concerns around complexity.
  • Stripping out complexity?

    • Export maps are complicated, but are a necessary feature for bridging the ESM and CJS worlds.
      • Trying to get it set up is rocket science, not supporting it would be worse.
  • "maybe I'm just old and grumpy"

    • "no this sucks"
  • We should be able to explain the happy path to people.

  • We have a lot of concern over how easily we'll be able to communicate best practices here; this is not just something that can affect TypeScript, the complexity can significantly hurt Node.js too.

created time in 18 hours

Pull request review commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

 async function foo(): Promise<void> { 
    // Legal to use 'await' in a type context.
    var v: await;
->v : any
+>v : await

A parenthesized type might work like (/*unresolved*/ await)

ahejlsberg

comment created time in 21 hours

PullRequestReviewEvent

pull request commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

or just globals like we do for the type symbols

I think just a global scope makes enough sense; if you do have a bunch of unresolved variables spread throughout your codebase, it's convenient to find-all-references, and likely to be a global anyhow; if it's mostly local (e.g. a user forgot to locally declare it), it doesn't really matter where you put it. But I'd understand if we wanted to take it one step at a time.

ahejlsberg

comment created time in 21 hours

issue commentmicrosoft/TypeScript

TSServer responses requesting further files to be opened

  • We should consider whether or not there's some "eager" loading we want to do, and whether there's some sort of memory limit, and how we should bail out if we cross that.
  • We want to avoid any behavior that doesn't feel "predictable" in some way.
  • We think the assumption that the editor will always have a directory listing actually isn't true, so it might not be "cheap" to delegate that task to an editor. This is a pre-requisite for doing anything in this domain.
    • On top of that, it's unclear what sort of performance characteristics we can expect for loading up directory entries and file contents.
DanielRosenwasser

comment created time in 21 hours

pull request commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

Would we say that this also fixes #38836?

ahejlsberg

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

 namespace ts {             const noTruncation = compilerOptions.noErrorTruncation || flags & TypeFormatFlags.NoTruncation;
             const typeNode = nodeBuilder.typeToTypeNode(type, enclosingDeclaration, toNodeBuilderFlags(flags) | NodeBuilderFlags.IgnoreErrors | (noTruncation ? NodeBuilderFlags.NoTruncation : 0), writer);
             if (typeNode === undefined) return Debug.fail("should always get typenode");
-            const options = { removeComments: true };
+            const options = { removeComments: type !== unresolvedType };

Would be helpful to leave a comment on this one (pun intended).

            // The unresolved type gets a synthesized comment on `any` 
            // to hint to users that it's not a plain `any`.
            // Otherwise, we always strip comments out.
            const options = { removeComments: type !== unresolvedType };
ahejlsberg

comment created time in 2 days

Pull request review commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

 async function foo(): Promise<void> { 
    // Legal to use 'await' in a type context.
    var v: await;
->v : any
+>v : await

Is there some way to make the type writer a little smarter here so that the team can differentiate between an unresolved and a concrete type?

ahejlsberg

comment created time in 2 days

Pull request review commentmicrosoft/TypeScript

Create type aliases for unresolved type symbols

 namespace ts {             return type && (type.flags & TypeFlags.Any) !== 0;
         }
 
+        function isErrorType(type: Type) {
+            return type === errorType || !!(type.flags & TypeFlags.Any && type.aliasSymbol);

Why not just this? Seems like it'd be cheaper too.

            return type === errorType || type === unresolvedType;
ahejlsberg

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

issue openedmicrosoft/TypeScript

Ensure @typescript/[lib] package names are explicitly prefixed with `lib`

To make it easier to search, TypeScript should ensure that its lib packages always start with lib.

created time in 2 days

issue commentmicrosoft/TypeScript

Investigate undocumented readDirectory change

Looks like there's a clear mistake where every function in getFileMatcherPatterns should take absolutePath, but getBasePaths doesn't.

-            basePaths: getBasePaths(path, includes, useCaseSensitiveFileNames)
+            basePaths: getBasePaths(absolutePath, includes, useCaseSensitiveFileNames)
DanielRosenwasser

comment created time in 2 days

pull request commentmicrosoft/TypeScript

Experimentally revert "Reduce exceptions"

@typescript-bot pack this

DanielRosenwasser

comment created time in 2 days

PR opened microsoft/TypeScript

Experimentally revert "Reduce exceptions"

Reverts microsoft/TypeScript#44710 to see if it's an internal culprit in a perf regression.

+7 -17

0 comment

5 changed files

pr created time in 2 days

create barnchmicrosoft/TypeScript

branch : revert-44710-ReduceExceptions

created branch time in 2 days

issue openedmicrosoft/TypeScript

Investigate undocumented readDirectory Change

@amcasey Hi! I don't know if it the right place to ask a question but I found this thread relative to the problem (I'm sorry if it's not). Should directoryExists be called with an absolute path like directoryExists(combinePaths(currentDirectory, basePath))?

I came across the undocumented breaking change in 4.4-beta that causes (for example) ts.sys.readDirectory("", [".ts",".tsx",".d.ts"],["node_modules","dist"],["**/*"]) to return an empty array. Before 4.4-beta it has been returning the correct array of files. So I wonder if it is a bug or desired behaviour.

Thank you in advance.

Originally posted by @gretzkiy in https://github.com/microsoft/TypeScript/pull/44710#r709064444

created time in 2 days

push eventmicrosoft/TypeScript

Daniel Rosenwasser

commit sha 61acd83187f5cb4b41138777be3f9fa50588980f

Experiment to pre-allocate some containers.

view details

push time in 3 days

issue commentmicrosoft/TypeScript

type infered from Template Literay Type is wrong

Shorter example

type Schema = {
    a: {
        b: {
            c: number
        }
    }
}

declare function chain<F extends keyof Schema>(field: F | `${F}.${F}`): void;
chain("a")

I'm guessing what happens is that when we try to infer from a string literal type to a template string type, we assume that we should infer never for each type parameter rather than not inferring at all.

zyf0330

comment created time in 3 days

Pull request review commentmicrosoft/TypeScript

Added Jsx Snippet Completion feature

 namespace ts.Completions {             hasAction = !importCompletionNode;
         }
 
+        const kind = SymbolDisplay.getSymbolKind(typeChecker, symbol, location); // TODO: GH#18217

There's no type assertion here, right?

        const kind = SymbolDisplay.getSymbolKind(typeChecker, symbol, location);
armanio123

comment created time in 3 days

PullRequestReviewEvent

create barnchmicrosoft/TypeScript

branch : preallocateContainers

created branch time in 6 days

issue commentdotnet/csharplang

[Proposal]: Remove restriction that interpolations within a non-verbatim interpolated string cannot contain new-lines.

FYI, you can use diff as the code fence language, so

```diff
 single_regular_balanced_text_character
-     : '<Any character except / (U+002F), @ (U+0040), \" (U+0022), $ (U+0024), ( (U+0028), ) (U+0029), [ (U+005B), ] (U+005D), { (U+007B), } (U+007D) and new_line_character>'
-     | '</ (U+002F), if not directly followed by / (U+002F) or * (U+002A)>'
+     : <Any character except @ (U+0040), \" (U+0022), $ (U+0024), ( (U+0028), ) (U+0029), [ (U+005B), ] (U+005D), { (U+007B), } (U+007D)>
+     | comment
     ;
```

will render as

 single_regular_balanced_text_character
-     : '<Any character except / (U+002F), @ (U+0040), \" (U+0022), $ (U+0024), ( (U+0028), ) (U+0029), [ (U+005B), ] (U+005D), { (U+007B), } (U+007D) and new_line_character>'
-     | '</ (U+002F), if not directly followed by / (U+002F) or * (U+002A)>'
+     : <Any character except @ (U+0040), \" (U+0022), $ (U+0024), ( (U+0028), ) (U+0029), [ (U+005B), ] (U+005D), { (U+007B), } (U+007D)>
+     | comment
     ;
CyrusNajmabadi

comment created time in 6 days

issue commentmicrosoft/TypeScript

Design Meeting Notes, 9/17/2021

It's looking more like we will keep ourselves open to being able to check specifiers based on a global type (in the same spirit of ImportMeta. That way, Deno's .d.ts files would be able to communicate exactly which extensions it supports.

DanielRosenwasser

comment created time in 6 days

issue openedmicrosoft/TypeScript

Design Meeting Notes, 9/17/2021

Import Assertions

https://github.com/microsoft/TypeScript/pull/40698

  • Basic idea, adds some additional syntax to import statements.
  • Doesn't affect us, we just need to "support" it by ignoring it.
  • Allows a runtime to assert that some import shouldn't have any executable code.
  • Looks like an object that you can stuff some options into.
  • Do we need a global interface that declares the valid properties?
    • This would only affect dynamic import() right?
  • Liked the idea of just supporting this and washing our hands of the host-specific details.
    • But seems like any host where this matters would have users savvy enough to add details here.
  • Where do these live?
    • JSON is "universally accepted" in TC39, so maybe that goes in lib.es****.d.ts
    • CSS - maybe lib.dom.d.ts.
  • How does this affect bundlers vs browser?
    • In theory shouldn't affect things.
    • This is contentious in the community.
    • Not sure what to do about this. 🤷‍♂️
  • Feels incomplete to pass in non-string values,
  • We'll start with the current changes, then follow-up with stricter types.

Type Display for Unresolved Types

https://github.com/microsoft/TypeScript/issues/45893 https://github.com/microsoft/TypeScript/issues/38836

  • Hover over parameters: we can preserve the type
  • Hovering over the type gives you type Thing = any
  • Now find all references works at least for within the file.
  • Dotted names are trickier.
    • What if you can resolve the namespaces but not the name itself.
  • Shying away from the idea of displaying unresolved types differently - we try to preserve what you wrote in print-back.
  • Currently only works for types - we could make it work for variables.
    • If we supported variables that are unresolved, it would light up misconfigured JS projects.
    • Deeper properties would be nice!
      • In fact, namespaces and property accesses are necessary to support namespace-style imports (i.e. import * as yadda).
      • Dotted type names, we intend to support.
      • Can speculate we try to create a symbol on the fly for a property.
        • Only aids find-all-refs.
        • Rename too.
          • Might not recommend doing that.
          • Not a safe refactoring.
      • How would you represent this?
        • Global map in checker?
  • Doesn't only work in syntax-only mode - also is supported in full semantic mode where code is broken.

created time in 6 days