| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This ensures the deno executable is properly created before running the integration tests.
Also allows deno_cli to be used as a lib. Docs are now properly generated: https://docs.rs/deno_cli/0.18.4/deno_cli/
Towards #2933
Prep for #2955
|
|
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: LE GOFF Vincent <g_n_s@hotmail.fr>
|
|
To better distinguish the deno_core crate from the executable deno,
which will now be called "the cli" internally.
|
|
A major API change was that asserts are imported from testing/asserts.ts
now rather than testing/mod.ts and assertEqual as renamed to
assertEquals to conform to what is most common in JavaScript.
|
|
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.
|
|
Co-authored-by: Greg Altman <g.s.altman@gmail.com>
|
|
|
|
and removeSync(), removeAllSync().
|
|
|
