diff options
author | John Spurlock <john.spurlock@gmail.com> | 2021-04-01 04:19:45 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-04-01 20:19:45 +1100 |
commit | f9ced5cc149c10df6b6a5b04691e89eee0f2c9db (patch) | |
tree | 6f6b34451ac697a417110cd71152a7dab7aadd61 | |
parent | ec6317e8944d87cb412128f44fe4bb4c2a2d136f (diff) |
Fix typo in faqs.md (#9948)
Co-authored-by: Kitson Kelly <me@kitsonkelly.com>
-rw-r--r-- | docs/typescript/faqs.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/typescript/faqs.md b/docs/typescript/faqs.md index 338537fc8..65f1d92b7 100644 --- a/docs/typescript/faqs.md +++ b/docs/typescript/faqs.md @@ -6,9 +6,9 @@ Maybe. That is the best answer, we are afraid. For lots of reasons, Deno has chosen to have fully qualified module specifiers. In part this is because it treats TypeScript as a first class language. Also, Deno uses explicit module resolution, with no _magic_. This is effectively the same way browsers -themselves work, thought they don't obviously support TypeScript directly. If -the TypeScript modules use imports that don't have these design decisions in -mind, they may not work under Deno. +themselves work, though they don't obviously support TypeScript directly. If the +TypeScript modules use imports that don't have these design decisions in mind, +they may not work under Deno. Also, in recent versions of Deno (starting with 1.5), we have started to use a Rust library to do transformations of TypeScript to JavaScript in certain |