foster/denoland-deno
0
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2025-02-02 04:38:21 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/tests/types.out

17 lines
300 B
Text
Raw Normal View History

Fixed copyright of types output
2019-01-17 20:21:10 +09:00
// Copyright 2018-2019 the Deno authors. All rights reserved. MIT license.
Improve integration test harness (#1142)
2018-11-05 06:52:31 +11:00
/// <reference no-default-lib="true" />
/// <reference lib="esnext" />
Add Deno global namespace (#1748) Resolves #1705 This PR adds the Deno APIs as a global namespace named `Deno`. For backwards compatibility, the ability to `import * from "deno"` is preserved. I have tried to convert every test and internal code the references the module to use the namespace instead, but because I didn't break compatibility I am not sure. On the REPL, `deno` no longer exists, replaced only with `Deno` to align with the regular runtime. The runtime type library includes both the namespace and module. This means it duplicates the whole type information. When we remove the functionality from the runtime, it will be a one line change to the library generator to remove the module definition from the type library. I marked a `TODO` in a couple places where to remove the `"deno"` module, but there are additional places I know I didn't mark.
2019-02-13 02:08:56 +11:00
declare namespace Deno {
Improve integration test harness (#1142)
2018-11-05 06:52:31 +11:00
[WILDCARD]
}
Add Deno global namespace (#1748) Resolves #1705 This PR adds the Deno APIs as a global namespace named `Deno`. For backwards compatibility, the ability to `import * from "deno"` is preserved. I have tried to convert every test and internal code the references the module to use the namespace instead, but because I didn't break compatibility I am not sure. On the REPL, `deno` no longer exists, replaced only with `Deno` to align with the regular runtime. The runtime type library includes both the namespace and module. This means it duplicates the whole type information. When we remove the functionality from the runtime, it will be a one line change to the library generator to remove the module definition from the type library. I marked a `TODO` in a couple places where to remove the `"deno"` module, but there are additional places I know I didn't mark.
2019-02-13 02:08:56 +11:00
[WILDCARD]
Improve integration test harness (#1142)
2018-11-05 06:52:31 +11:00
declare interface Window {
[WILDCARD]
Add Deno global namespace (#1748) Resolves #1705 This PR adds the Deno APIs as a global namespace named `Deno`. For backwards compatibility, the ability to `import * from "deno"` is preserved. I have tried to convert every test and internal code the references the module to use the namespace instead, but because I didn't break compatibility I am not sure. On the REPL, `deno` no longer exists, replaced only with `Deno` to align with the regular runtime. The runtime type library includes both the namespace and module. This means it duplicates the whole type information. When we remove the functionality from the runtime, it will be a one line change to the library generator to remove the module definition from the type library. I marked a `TODO` in a couple places where to remove the `"deno"` module, but there are additional places I know I didn't mark.
2019-02-13 02:08:56 +11:00
Deno: typeof Deno;
Improve integration test harness (#1142)
2018-11-05 06:52:31 +11:00
}
declare const window: Window;
[WILDCARD]
Copy permalink