This changes the lockfile to not store JSR specifiers in the "remote"
section. Instead a single JSR integrity is stored per package in the
lockfile, which is a hash of the version's `x.x.x_meta.json` file, which
contains hashes for every file in the package. The hashes in this file
are then compared against when loading.
Additionally, when using `{ "vendor": true }` in a deno.json, the files
can be modified without causing lockfile errors—the checksum is only
checked when copying into the vendor folder and not afterwards
(eventually we should add this behaviour for non-jsr specifiers as
well). As part of this change, the `vendor` folder creation is not
always automatic in the LSP and running an explicit cache command is
necessary. The code required to track checksums in the LSP would have
been too complex for this PR, so that all goes through deno_graph now.
The vendoring is still automatic when running from the CLI.
Based on #21074 and #20741 I was looking for further potential use cases
of `TransformStream` `cancel()` method, so here go `CompressionStream`
and `DecompressionStream`.
Fixes #14212
Note: tests are not the only part of the codebase that uses `std`. Other
parts, like `tools/`, do too. So, it could be argued that this is a
little misleading. Either way, I'm doing this as discussed with
@mmastrac.
This implementation heavily depends on there being a lockfile, meaning
JSR specifiers will always diagnose as uncached unless it's there. In
practice this affects cases where a `deno.json` isn't being used. Our
NPM specifier support isn't subject to this.
The reason for this is that the version constraint solving code is
currently buried in `deno_graph` and not usable from the LSP, so the
only way to reuse that logic is the solved-version map in the lockfile's
`packages.specifiers`.
This looks like a massive PR, but it's only a move from cli/tests ->
tests, and updates of relative paths for files.
This is the first step towards aggregate all of the integration test
files under tests/, which will lead to a set of integration tests that
can run without the CLI binary being built.
While we could leave these tests under `cli`, it would require us to
keep a more complex directory structure for the various test runners. In
addition, we have a lot of complexity to ignore various test files in
the `cli` project itself (cargo publish exclusion rules, autotests =
false, etc).
And finally, the `tests/` folder will eventually house the `test_ffi`,
`test_napi` and other testing code, reducing the size of the root repo
directory.
For easier review, the extremely large and noisy "move" is in the first
commit (with no changes -- just a move), while the remainder of the
changes to actual files is in the second commit.
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
Instead of using core/snapshot_creator.rs, instead two crates are
introduced which allow building the snapshot during build.rs.
Rollup is removed and replaced with our own bundler. This removes
the Node build dependency. Modules in //js now use Deno-style imports
with file extensions, rather than Node style extensionless imports.
This improves incremental build time when changes are made to //js files
by about 40 seconds.
This removes dispatch_flatbuffers as it is now unused. There are still a
few places where msg_generated is used: ErrorKind and MediaType. These
will be dealt with later.
* Revert "port more ops to JSON (#2809)"
This reverts commit 137f33733d.
* Revert "port ops to JSON: compiler, errors, fetch, files (#2804)"
This reverts commit 79f82cf10e.
* Revert "Port rest of os ops to JSON (#2802)"
This reverts commit 5b2baa5c99.
* remove fetch_source_file_and_maybe_compile_async and
replace it with State.fetch_compiled_module
* remove SourceFile.js_source()
* introduce CompiledModule which is basically the same as
deno::SourceInfo and represents arbitrary file that has been
compiled to JS module
* introduce //cli/compilers module containing all compilers
* introduce JsCompiler which is a no-op compiler
- output is the same as input, no compilation takes place
- it is used for MediaType::JavaScript and MediaType::Unknown
* introduce JsonCompiler that wraps JSON in default export
* support JS-to-JS compilation using checkJs
* rename `ModuleMetaData` to `SourceFile` and remove TS specific
functionality
* add `TsCompiler` struct encapsulating processing of TypeScript files
* move `SourceMapGetter` trait implementation to `//cli/compiler.rs`
* add low-level `DiskCache` API for general purpose caches and use it in
`DenoDir` and `TsCompiler` for filesystem access
* don't use hash-like filenames for compiled modules, instead use
metadata file for storing compilation hash
* add `SourceFileCache` for in-process caching of loaded files for fast
subsequent access
* define `SourceFileFetcher` trait encapsulating loading of local and
remote files and implement it for `DenoDir`
* define `use_cache` and `no_fetch` flags on `DenoDir` instead of using
in fetch methods
The rules are now as follows:
* In `import` statements, as mandated by the WHATWG specification,
the import specifier is always treated as a URL.
If it is a relative URL, it must start with either / or ./ or ../
* A script name passed to deno as a command line argument may be either
an absolute URL or a local path.
- If the name starts with a valid URI scheme followed by a colon, e.g.
'http:', 'https:', 'file:', 'foo+bar:', it always interpreted as a
URL (even if Deno doesn't support the indicated protocol).
- Otherwise, the script name is interpreted as a local path. The local
path may be relative, and operating system semantics determine how
it is resolved. Prefixing a relative path with ./ is not required.
* Compiler no longer has its own Tokio runtime. Compiler handles one
message and then exits.
* Uses the simpler ts.CompilerHost interface instead of
ts.LanguageServiceHost.
* avoids recompiling the same module by introducing a hacky but simple
`hashset<string>` that stores the module names that have been already
compiled.
* Removes the CompilerConfig op.
* Removes a lot of the mocking stuff in compiler.ts like `this._ts`. It
is not useful as we don't even have tests.
* Turns off checkJs because it causes fmt_test to die with OOM.
Removed `extmap` and added .mjs entry in `map_file_extension`.
The assert in the compiler does not need to be updated, since it is
resolving from the compiled cache instead of elsewhere (notice the .map
is asserted next to it)
This disables a few tests which are broken still:
- tests/error_004_missing_module.test
- tests/error_005_missing_dynamic_import.test
- tests/error_006_import_ext_failure.test
- repl_test test_set_timeout
- repl_test test_async_op
- repl_test test_set_timeout_interlaced
- all of permission_prompt_test
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.
* Native ES modules
This is a major refactor of internal compiler.
Before: JS and TS both were sent through the typescript compiler where
their imports were parsed and handled. Both compiled to AMD JS and
finally sent to V8
Now: JS is sent directly into V8. TS is sent through the typescript
compiler, but tsc generates ES modules now instead of AMD. This
generated JS is then dumped into V8.
This should much faster for pure JS code. It may improve TS compilation
speed.
In the future this allows us to separate TS out of the runtime heap and
into its own dedicated snapshot. This will result in a smaller runtime
heap, and thus should be faster.
Some tests were unfortunately disabled to ease landing this patch:
1. compiler_tests.ts which I intend to bring back in later commits.
2. Some text_encoding_test.ts tests which made the file invalid utf8.
See PR for a discussion.
Also worth noting that this is necessary to support WASM
- Improves speed and binary size significantly.
- Makes deno_last_exception() output a JSON structure.
- Isolate::execute and Isolate::event_loop now return
structured, mapped JSError objects on errors.
- Removes libdeno functions:
libdeno.setGlobalErrorHandler()
libdeno.setPromiseRejectHandler()
libdeno.setPromiseErrorExaminer()
In collaboration with Ryan Dahl.
* Changed tools/lint.py to lint the entire js and tests directorys and sub directories, currently it was pointing at tsconfig and would only lint files that were part of js/main.ts or node_modules/typescript/lib/lib.esnext.d.ts and their dependencies
* Broke the typescript linting out into separate steps for the main typescript programing and tests.
* Fixed linting issues in ts tests.
Windows can't handle ":" in path names, so we use a special directory
format .deno/deps/localhost_PORT4545/ to represent hosts with
non-default ports.
Fixes #645.
