Remove deno_typescript (#6813)

This commit is contained in:
Ryan Dahl 2020-07-20 19:49:57 -04:00 committed by GitHub
parent 903d28f872
commit 2460689b1a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
17 changed files with 23 additions and 148 deletions

View File

@ -12,7 +12,7 @@
"includes": ["**/*.{ts,tsx,js,jsx,json,md}"],
"excludes": [
".cargo_home",
"deno_typescript/typescript",
"cli/typescript",
"gh-pages",
"std/**/testdata",
"std/**/vendor",

2
.gitmodules vendored
View File

@ -2,7 +2,7 @@
path = third_party
url = https://github.com/denoland/deno_third_party.git
[submodule "typescript"]
path = deno_typescript/typescript
path = cli/typescript
url = https://github.com/microsoft/TypeScript.git
fetchRecurseSubmodules = false
shallow = true

10
Cargo.lock generated
View File

@ -386,7 +386,6 @@ dependencies = [
"clap",
"deno_core",
"deno_lint",
"deno_typescript",
"dissimilar",
"dlopen",
"futures 0.3.5",
@ -459,15 +458,6 @@ dependencies = [
"swc_ecma_visit",
]
[[package]]
name = "deno_typescript"
version = "0.49.0"
dependencies = [
"deno_core",
"serde",
"serde_json",
]
[[package]]
name = "derive_deref"
version = "1.1.1"

View File

@ -2,7 +2,6 @@
members = [
"cli",
"core",
"deno_typescript",
"test_plugin",
"test_util",
]

View File

@ -16,7 +16,8 @@ path = "main.rs"
[build-dependencies]
deno_core = { path = "../core", version = "0.49.0" }
deno_typescript = { path = "../deno_typescript", version = "0.49.0" }
serde = { version = "1.0.112", features = ["derive"] }
serde_json = { version = "1.0.55", features = [ "preserve_order" ] }
[target.'cfg(windows)'.build-dependencies]
winres = "0.1"
@ -25,7 +26,6 @@ winapi = "0.3.8"
[dependencies]
deno_core = { path = "../core", version = "0.49.0" }
deno_lint = "0.1.16"
deno_typescript = { path = "../deno_typescript", version = "0.49.0" }
atty = "0.2.14"
base64 = "0.12.2"

View File

@ -5,4 +5,4 @@
This provides the actual deno executable and the user-facing APIs.
The deno crate uses the deno_core and deno_typescript to provide the executable.
The deno crate uses the deno_core to provide the executable.

View File

@ -1,4 +1,6 @@
// Copyright 2018-2020 the Deno authors. All rights reserved. MIT license.
//
mod op_fetch_asset;
use deno_core::js_check;
use deno_core::CoreIsolate;
@ -64,16 +66,23 @@ fn create_compiler_snapshot(
);
runtime_isolate.register_op(
"op_fetch_asset",
deno_typescript::op_fetch_asset(custom_libs),
op_fetch_asset::op_fetch_asset(custom_libs),
);
js_check(
runtime_isolate.execute("typescript.js", deno_typescript::TYPESCRIPT_CODE),
);
js_check(runtime_isolate.execute(
"typescript.js",
&std::fs::read_to_string("typescript/lib/typescript.js").unwrap(),
));
create_snapshot(runtime_isolate, snapshot_path, files);
}
fn ts_version() -> String {
let data = include_str!("typescript/package.json");
let pkg: serde_json::Value = serde_json::from_str(data).unwrap();
pkg["version"].as_str().unwrap().to_string()
}
fn main() {
// Don't build V8 if "cargo doc" is being run. This is to support docs.rs.
if env::var_os("RUSTDOCFLAGS").is_some() {
@ -81,12 +90,9 @@ fn main() {
}
// To debug snapshot issues uncomment:
// deno_typescript::trace_serializer();
// op_fetch_asset::trace_serializer();
println!(
"cargo:rustc-env=TS_VERSION={}",
deno_typescript::ts_version()
);
println!("cargo:rustc-env=TS_VERSION={}", ts_version());
println!(
"cargo:rustc-env=TARGET={}",

View File

@ -1,7 +1,5 @@
// Copyright 2018-2020 the Deno authors. All rights reserved. MIT license.
// TODO(ry) Combine this implementation with //deno_typescript/compiler_main.js
// This module is the entry point for "compiler" isolate, ie. the one
// that is created when Deno needs to compile TS/WASM to JS.
//

View File

@ -49,6 +49,7 @@ mod metrics;
mod module_graph;
pub mod msg;
pub mod op_error;
mod op_fetch_asset;
pub mod ops;
pub mod permissions;
mod repl;

View File

@ -1,7 +1,5 @@
// Copyright 2018-2020 the Deno authors. All rights reserved. MIT license.
extern crate deno_core;
extern crate serde;
extern crate serde_json;
// Note: this module is used both in build.rs and main.rs.
pub use deno_core::v8_set_flags;
use deno_core::CoreIsolateState;
@ -11,14 +9,6 @@ use deno_core::ZeroCopyBuf;
use std::collections::HashMap;
use std::path::PathBuf;
pub static TYPESCRIPT_CODE: &str = include_str!("typescript/lib/typescript.js");
pub fn ts_version() -> String {
let data = include_str!("typescript/package.json");
let pkg: serde_json::Value = serde_json::from_str(data).unwrap();
pkg["version"].as_str().unwrap().to_string()
}
fn get_asset(name: &str) -> Option<&'static str> {
macro_rules! inc {
($e:expr) => {

View File

@ -8,6 +8,6 @@ pub fn init(i: &mut CoreIsolate, _s: &State) {
// TODO(bartlomieju): is this op even required?
i.register_op(
"op_fetch_asset",
deno_typescript::op_fetch_asset(custom_assets),
crate::op_fetch_asset::op_fetch_asset(custom_assets),
);
}

View File

@ -2,9 +2,6 @@
Files in this directory are unit tests for Deno runtime.
They are run under compiled Deno binary as opposed to files in `cli/js/` which
are bundled and snapshotted using `deno_typescript` crate.
Testing Deno runtime code requires checking API under different runtime
permissions (ie. running with different `--allow-*` flags). To accomplish this
all tests exercised are created using `unitTest()` function.

View File

@ -1,24 +0,0 @@
[package]
name = "deno_typescript"
version = "0.49.0"
license = "MIT"
description = "To compile TypeScript to a snapshot during build.rs"
repository = "https://github.com/denoland/deno"
authors = ["the Deno authors"]
edition = "2018"
exclude = [
"typescript/tests/*",
"typescript/src/*",
"typescript/scripts/*",
"typescript/doc/*",
"typescript/lib/*/*.json",
]
[lib]
path = "lib.rs"
[dependencies]
deno_core = { path = "../core", version = "0.49.0" }
serde_json = "1.0.55"
serde = { version = "1.0.112", features = ["derive"] }

View File

@ -1,82 +0,0 @@
# Deno TypeScript Crate
[![crates](https://img.shields.io/crates/v/deno_typescript.svg)](https://crates.io/crates/deno_typescript)
[![docs](https://docs.rs/deno_typescript/badge.svg)](https://docs.rs/deno_typescript)
This crate provides utilities to compile typescript, bundle it up, and create a
V8 snapshot, all during build. Snapshots allow the executable to startup fast.
## `system_loader.js`
This is a minimalistic implementation of a
[System](https://github.com/systemjs/systemjs) module loader. It is specifically
designed to load modules that are emitted from TypeScript the module format is
`"system"` and a single `"outfile"` is supplied, which is commonly refereed to
as a bundle.
Because this loader becomes part of an emitted bundle under `Deno.bundle()` and
`deno bundle`, it has minimal comments and very terse and cryptic syntax, which
isn't very self documenting. Because of this, a guide to this file is provided
here.
A bundle of System modules expects a `System.register()` function to be in scope
for registering the modules. Modules that are emitted from TypeScript in a
single out file always pass 3 arguments, the module specifier, an array of
strings of modules specifiers that this module depends upon, and finally a
module factory.
The module factory requires two arguments to be passed, a function for exporting
values and a context object. We have to bind to some information in the
environment to provide these, so `gC` gets the context and `gE` gets the export
function to be passed to a factory. The context contains information like the
module specifier, a reference to the dynamic `import()` and the equivalent of
`import.meta`. The export function takes either two arguments of an named export
and its value, or an object record of keys of the named exports and the values
of the exports.
Currently, TypeScript does not re-write dynamic imports which resolve to static
strings (see
[microsoft/TypeScript#37429](https://github.com/microsoft/TypeScript/issues/37429)),
which means the import specifier for a dynamic import which has been
incorporated in the bundle does not automatically match a module specifier that
has been registered in the bundle. The `di()` function provides the capability
to try to identify relative import specifiers and resolve them to a specifier
inside the bundle. If it does this, it resolves with the exports of the module,
otherwise it simply passes the module specifier to `import()` and returns the
resulting promise.
The running of the factories is handled by `rF()`. When the factory is run, it
returns an object with two keys, `execute` and `setters`. `execute` is a
function which finalises that instantiation of the module, and `setters` which
is an array of functions that sets the value of the exports of the dependent
module.
The `gExp()` and `gExpA()` are the recursive functions which returns the exports
of a given module. It will determine if the module has been fully initialized,
and if not, it will gather the exports of the dependencies, set those exports in
the module via the `setters` and run the modules `execute()`. It will then
always return or resolve with the exports of the module.
As of TypeScript 3.8, top level await is supported when emitting ES or System
modules. When Deno creates a module bundle, it creates a valid, self-contained
ES module which exports the exports of the "main" module that was used when the
bundle was created. If a module in the bundle requires top-level-await, then the
`execute()` function is emitted as an async function, returning a promise. This
means that in order to export the values of the main module, the instantiation
needs to utilise top-level-await as well.
At the time of this writing, while V8 and other JavaScript engines have
implemented top-level-await, no browsers have it implemented, meaning that most
browsers could not consume modules that require top-level-await.
In order to allow more browsers to consume bundles, there is an argument that is
passed to the `__instantiate()` function which determines if the code is
bootstrapped asynchronously or not. When emitting a bundle that contains a
module that requires top-level-await, Deno will detect this and utilise
`await __instantiate(main, true)`.
The `system_loader_es5.js` is a transpiled version of `system_loader.js` that is
designed to work with ES5 or later, and will be used when the bundle target is <
ES2017. While ES3 is still a potential target which can be passed in a
`tsconfig.json` to Deno, any resulting bundle will not be compatible, as there
is a need to utilise items like `Object.defineProperty()`.