4 ms·

Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace

Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace will no longer be able to access the JavaScript native Date type. This also apparently isn't something they're inclined to fix. [0] The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclude entire directories. So if I want to simply compile everything in the "src" directory, my best option is to exclude every other directory. [0] https://github.com/Microsoft/TypeScript/issues/983 https://github.com/Microsoft/TypeScript/issues/983

emodendroket 11y ago
Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems
- WorldMaker 11y ago
  Typescript's job is to add safeties to a lot of the JS footguns, but there are a lot of them if you are not careful, and also, even with a safety in place, some people just want to shoot themselves in the foot.
- jdmichal 11y ago
  No, because I'm shadowing the type, not overwriting it. JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awesome.Date`. And there's no way to explicitly reference the global scope, so within those namespaces the new type completely and irrevocably shadows the original JavaScript type. Also in JavaScript, unless I overwrite the original `Date` type, I can always explicitly scope it by saying `window.Date`. But TypeScript doesn't define `Date` within the `window` type, so I can't use that out either.
  - WorldMaker 11y ago
    Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output. Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous. That said, Typescript is more than happy to let you `(<any>window).Date` assert your way to that global. Or if you feel particularly strongly about this, you could in increasing order of strength of opinion: 1) add .d.ts file somewhere augment window yourself with Date, 2) fork the lib.d.ts and use your own instead of the default, 3) send a PR to Typescript adding it to the default lib.d.ts and see if they have a stronger reason for it not being there beyond it just being ambiguous in the JS language/spec/library.
    - jdmichal 11y ago
      > Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output. Yes, and in the transpiled output I will see `Date` turned into `my.awesome.Date` for files within the namespace scope. As I said, JavaScript is always explicitly scoped, so unless you shadow it with a local variable or overwrite the original, you can always access it. So I could easily write `my.awesome.Date` in JavaScript without shadowing the native `Date`, but I cannot do that in TypeScript because of the namespace scoping rules it adds. Which, pains of using TypeScript being the original prompt, seemed quite relevant.

emodendroket 11y ago

Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems

WorldMaker 11y ago
Typescript's job is to add safeties to a lot of the JS footguns, but there are a lot of them if you are not careful, and also, even with a safety in place, some people just want to shoot themselves in the foot.
jdmichal 11y ago
No, because I'm shadowing the type, not overwriting it. JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awesome.Date`. And there's no way to explicitly reference the global scope, so within those namespaces the new type completely and irrevocably shadows the original JavaScript type. Also in JavaScript, unless I overwrite the original `Date` type, I can always explicitly scope it by saying `window.Date`. But TypeScript doesn't define `Date` within the `window` type, so I can't use that out either.
- WorldMaker 11y ago
  Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output. Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous. That said, Typescript is more than happy to let you `(<any>window).Date` assert your way to that global. Or if you feel particularly strongly about this, you could in increasing order of strength of opinion: 1) add .d.ts file somewhere augment window yourself with Date, 2) fork the lib.d.ts and use your own instead of the default, 3) send a PR to Typescript adding it to the default lib.d.ts and see if they have a stronger reason for it not being there beyond it just being ambiguous in the JS language/spec/library.
  - jdmichal 11y ago
    > Typescript's following the usual JS scope closure rules: the namespace syntax is sugar for the usual sort of JS "IIFE" object pattern, which you should be able to plainly see in the transpiled output. Yes, and in the transpiled output I will see `Date` turned into `my.awesome.Date` for files within the namespace scope. As I said, JavaScript is always explicitly scoped, so unless you shadow it with a local variable or overwrite the original, you can always access it. So I could easily write `my.awesome.Date` in JavaScript without shadowing the native `Date`, but I cannot do that in TypeScript because of the namespace scoping rules it adds. Which, pains of using TypeScript being the original prompt, seemed quite relevant.