This commits adds support for "--config" flag in "deno install"
subcommand. Specified configuration file is copied alongside
source code to installation directory.
- Add more support for generics
- Add the --private flag - displays documentation for
not exported and private nodes
- Display more attributes like abstract, static and readonly
- Display type aliases
- Refactor module to use the Display trait
- Use a bit more color
This PR removes direct dependency on dprint-plugin-typescript
and swc_ecma_visit. Both of these dependencies have been
pushed out to deno_lint crate. This should make it a bit easier
to do the upgrades and prevent having conflicting crate requirements.
This commit adds a "--no-check" option to following subcommands:
- "deno cache"
- "deno info"
- "deno run"
- "deno test"
The "--no-check" options allows to skip type checking step and instead
directly transpiles TS sources to JS sources.
This solution uses `ts.transpileModule()` API and is just an interim
solution before implementing it fully in Rust.
Currently, the documentation makes it sound like the test subcommand's filter
flag could accept some kind of pattern matching value like a glob or a regex,
although the function "createFilterFn" accepts a regex as an argument, there's
no way to pass an actual regex value from the CLI.
This commit makes it possible to pass a string that could be cast as regex
when string matches "^/.*/$".
With this change, a user can use the filter flag as follow:
deno test --filter "/test-.+/"
Also tested that `\` get escaped properly, on MacOS at least, and this is
also a valid flag:
deno test --filter "/test-\d+/"
This commit adds incremental compilation capabilities to internal TS compiler.
Instead of using "ts.createProgram()" API for compilation step (during deno
startup), "ts.createIncrementalProgram()" API is used instead.
Thanks to TS' ".tsbuildinfo" file that already stores all necessary metadata
for compilation I was able to remove our own invention that is ".graph" file.
".tsbuildinfo" file is stored alongside compiled source and is used to
cache-bust outdated dependencies, facilitated by the "version" field.
The value for "version" field is computed in Rust during loading of module
graph and is basically a hash of the file contents.
Please keep in mind that incremental compilation is only used for initial
compilation (or dynamic imports compilation) - bundling and runtime compiler
APIs haven't been changed at all.
Due to problems with source map I changed compilation settings to inline
source map (inlineSourceMap instead of sourceMap).
The following used to fail in Deno despite working in the browser:
```javascript
new Request('http://localhost/', {method: 'POST', body: new URLSearchParams({hello: 'world'})}).text().then(console.log)
```
This commit adds alternate dispatch method to core JS API.
"Deno.core.dispatchByName()" works like "Deno.core.dispatch()",
but takes op name instead of op id as a first argument.
* refactor "compile" and "runtimeCompile" in "compiler.ts" and factor out
separate methods for "compile" and "bundle" operations
* remove noisy debug output from "compiler.ts"
* provide "Serialize" implementations for enums in "msg.rs"
* rename "analyze_dependencies_and_references" to "pre_process_file" and
move it to "tsc.rs"
* refactor ModuleGraph to use more concrete types and properly annotate
locations where errors occur
* remove dead code from "file_fetcher.rs" - "SourceFile.types_url" is no
longer needed, as type reference parsing is done in "ModuleGraph"
* remove unneeded field "source_path" from ".meta" files stored for
compiled source file (towards #6080)
This commit provides a "system_loader_es5.js" bundle loader which will be added
to the bundle when the target is < ES2017, which is the minimum target syntax
required for "system_loader.js".
Supports #5913 (via Deno.bundle()) with a couple caveats:
* Allowing "deno bundle" to take a different target is not supported, as we
specifically ignore "target" when passed in a TypeScript config file. This is
because deno bundle is really intended to generate bundles that work in Deno.
It is an unintentional side effect that some bundles are loadable in browsers.
* While a target of "es3" will be accepted, the module loader will still only be
compatible with ES5 or later. Realistically no one should be expecting bundles
generated by Deno to be used on IE8 and prior, and there is just too much
"baggage" to support that at this point.
This is a minor variation of 75bb9d, which exposed some sort of internal V8 bug.
Ref #6358
This is 100% authored by Kitson Kelly. Github might change the author when landing
so I'm leaving this in:
Co-authored-by: Kitson Kelly <me@kitsonkelly.com>
This commit provides a "system_loader_es5.js" bundle loader which will be added
to the bundle when the target is < ES2017, which is the minimum target syntax
required for "system_loader.js".
Supports #5913 (via Deno.bundle()) with a couple caveats:
* Allowing "deno bundle" to take a different target is not supported, as we
specifically ignore "target" when passed in a TypeScript config file. This is
because deno bundle is really intended to generate bundles that work in Deno.
It is an unintentional side effect that some bundles are loadable in browsers.
* While a target of "es3" will be accepted, the module loader will still only be
compatible with ES5 or later. Realistically no one should be expecting bundles
generated by Deno to be used on IE8 and prior, and there is just too much
"baggage" to support that at this point.
The tests for testing that `Deno.truncateSync` and `Deno.truncate`
require write permissions seem to not call the functions they are
testing *at all* and are calling `Deno.mkdir` and `Deno.mkdirSync`
instead.
This commit replaces those calls with calls to `Deno.truncateSync`
and `Deno.truncate` respectively.
Currently WebAssembly runtime errors don't propagate up to the user as
they use urls to denote where the error occurred which get caught by the source-map
pipeline which doesn't support the wasm scheme.
This commit:
* added default file globs so "deno lint" can be run
without arguments (just like "deno fmt")
* added test for globs in "deno lint"
* upgrade "deno_lint" crate to v0.1.9
This commit fixes several regressions in TS compiler:
* double compilation of same module during same process run
* compilation of JavaScript entry point with non-JS imports
* unexpected skip of emit during compilation
Additional checks were added to ensure "allowJs" setting is
used in TS compiler if JavaScript has non-JS dependencies.
Currently sync operations on stdin are failing because tokio::Stdin
cannot be converted to a std::File.
This commit replaces tokio::stdin with a raw file descriptor
wrapped in a std::fs::File which can be converted to a
tokio::File and back again making the synchronous version
of op_read actually work.
$HOME is meaningless on Windows. It may be set by users or by third
party software, but it is non-standard and should not be relied upon.
Likewise, $USERPROFILE is meaningless on other platforms.
This reverts commit c4c6a8dae4
There is some controversy about this change because vscode doesn't interpret the fragments correctly. Needs more discussion before landing.
This commit fixes regression that caused TS dependencies
not being compiled.
Check was added that ensures TS compiler is run if
any of dependencies in module graph is TS/TSX/JSX.
This PR addresses many problems with module graph loading
introduced in #5029, as well as many long standing issues.
"ModuleGraphLoader" has been wired to "ModuleLoader" implemented
on "State" - that means that dependency analysis and fetching is done
before spinning up TS compiler worker.
Basic dependency tracking for TS compilation has been implemented.
Errors caused by import statements are now annotated with import
location.
Co-authored-by: Ryan Dahl <ry@tinyclouds.org>
Since everything that Deno loads is treated as an ES Module,
it means that all code is treated as "use strict" except for
when using the REPL. This PR changes that so code in the
REPL is also always evaluated with "use strict". There are
also a couple other places where we load code as scripts
which should also use "use strict" just in case.
