# global * JS * PR: https://github.com/Microsoft/TypeScript/pull/22891 * issues: * type: https://github.com/Microsoft/TypeScript/issues/19816 * value (TC39): https://github.com/Microsoft/TypeScript/issues/12902 * namespace: https://github.com/Microsoft/TypeScript/issues/983 Issue comes in the context of recognizing assignments to properties on `this` or `window` as global declarations. We need way to refer to the global type, e.g. `declare var window: Window & global;` for DOM. We have a precedence in the `declare global { .. }` support. Some options: ```ts // use new `import("module")` syntax with `global` instead var window: Window & import(global); // or no operand at all var nan: typeof import().NAN; // import.meta? import.meta.global // C++ anyone? var x: global::NaN // call it `global` or just `Global` var x1: Global; var x1: typeof Global; var x1: Global.Array<number> var x1: Global["NaN"]; var x1: typeof Global.NaN; ``` TC39 has been looking into a name for the value side of global https://github.com/tc39/proposal-global, the proposal is at stage 3. The proposal has stalled on the choice of the variable name, `global` seems to be already in use. @rbuckton contacted the proposal champion (@ljharb), and the proposal is still active. there are few names proposed at this point. Conclusion, wait for TC39 to pick a name, and then use that in both type and value positions. # Resolving .json files * PR: https://github.com/Microsoft/TypeScript/pull/22167 * issue: https://github.com/Microsoft/TypeScript/issues/7071 * Concerns: * .json files can be large, this can impact performance of a compilation * should we put it under a switch? * probably * limit the file size, and if larger than limt, return any.. implicit any maybe * does not seem right * files can be huge * many of them * but it is useful for completions.. * it is good for language service, and for .js file experience * no contextual type here, do we need a way to "impose" a type on the .json file? * seems like an orthogonal issue * taking the discussion offline until we address the concerns above # Allow `infer` types in expression type argument positions * PR: https://github.com/Microsoft/TypeScript/pull/22368 * @weswigham, this is probably too much power, not clear what use cases require that. * the change is simple, relatively, thought * practically gives you associated types * We still need named type parameters, what to do when you wnat to specify the fifth type parameter and get everything inferred * we already have a proposal here, no need for another proposal # `Array.isArray` and `ReadonlyArray` * PR: https://github.com/Microsoft/TypeScript/pull/22942 * it is a breaking change, we are just trading one set of problems with another * should not change it * the core issue is that `Array` and `ReadonlyArray` are two distinct types. we need to think about a `readonly` modifier again # Variadic types * look at `bindCallback` in https://github.com/Microsoft/TypeScript/issues/22952#issuecomment-377338534 * we need: * a concept of an infinite tuple * a way to declare optional members in a tuple * a grand unified theory of tuples and function parameters * make all of that work in higher order