Previously, to get the svelte template (`npx sv create`) to work under
Deno, a knowledgeable user would have to convert the compiler options
under `.svelte-kit/tsconfig.json` to a `deno.json`. This catches up
Deno's tsconfig support so they don't have to change anything.
Currently, importing a module only for its side effect results in an
`ERR_TYPES_NOT_FOUND` error with `nodeModulesDir=manual`.
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
- Each workspace directory is probed for a `tsconfig.json`.
- These and any that are included by their `references` are put into a
list ordered by priority.
- A tsconfig has lower priority than its `references`.
- An earlier listed entry in `references` has higher priority than a
later one.
- A probed tsconfig in an inner directory has higher priority than an
outer one. Their `references` would be interspersed between them.
- Each tsconfig has a filter based on its `files`, `include` and
`exclude` fields. If it doesn't have `files` or `include`, it will match
any path in its containing directory not exempted by `exclude`.
- For type-checking, each root path will be allocated compiler options
based on the first tsconfig it whose filter it matches from this list.
- Only if it doesn't match any tsconfig, it will fall back to using the
nearest `deno.json`. If it's a workspace member and the root `deno.json`
has `compilerOptions`, these will be merged using the same logic from
`extends`.
Inheritance between configs strictly occurs via `extends` in a
`tsconfig.json`, and between workspace member and root `deno.json`s'
`compilerOptions`. There is no implicit inheritance between
`tsconfig.json` and `deno.json`.
The default compiler options currently applied against tsconfigs are
Deno's normal defaults, with the exception of `lib`. The default value
for `lib` is `["deno.window", "deno.unstable", "dom"]` for files in the
scope of a tsconfig with `lib` unspecified. This behaviour is depended
on by, for example, the template project created by `create-vite ->
svelte`. I expect we'll add more such exceptions over time with other
fields.
This commit makes `deno check` ignore `Cannot find module` diagnostic if the
missing module specifier matches one of ambient module pattern. (For
example if there's `declare module "*.svg" { ... }` declaration in one
of d.ts files, importing of `<any>.svg` doesn't cause type error with
this change. This is necessary for passing the type checking of default
vite template.)
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
This PR adds detection of `tsconfig.json` at the root of a workspace
when there exists either a deno.json or package.json. If a project
already has `deno.json` with a `compilerOptions` value the
`tsconfig.json` is ignored.
Fixes https://github.com/denoland/deno/issues/27569.
Fixes https://github.com/denoland/deno/issues/27215.
This PR makes it so type resolution falls back to looking for definitely
typed packages (`@types/foo`) if a given NPM package does not contain
type declarations.
One complication is choosing _which_ version of the `@types/*` package
to use, if the project depends on multiple versions. The heuristic here
is to try to match the major and minor versions, falling back to the
latest version. So if you have
```
@types/foo: 0.1.0, 0.2.0, 3.1.0, 3.1.2, 4.0.0
foo: 3.1.0
```
we would choose `@types/foo@3.1.2` when resolving types for `foo`.
---
Note that this only uses `@types/` packages if you _already_ depend on
them. So a follow up to this PR could be to add a diagnostic and
quickfix to install `@types/foo` if we don't find types for `foo`.
1. Allows resolving to `.ts` files for type checking.
2. Probes for `.ts` files to use for type checking.
To emphasize, this is only for type checking.
Fixes#26224.
Fixes#27042.
There were three bugs here:
- we were only resolving `/// <reference types` directives starting with
`npm:`, which meant we failed to resolve bare specifiers (this broke the
`/// <reference types="vite/client">` directive in most of the vite
templates)
- the `$node_modules` workaround caused us to fail to read files for
tsc. For instance tsc would construct new paths based on specifiers
containing `$node_modules`, and since we hadn't created those we weren't
mapping them back to the original (this broke some type resolution
within `vite/client`)
- our separation of `ImportMeta` across node and deno globals in tsc
meant that npm packages couldn't augment `ImportMeta` (this broke
`vite/client`'s augmentation to add `import.meta.env` and others)
After this, the only remaining issue in the vanilla vite template is our
error on `/vite.svg` (which is an ambient module), and I'll look into
that next.
Fixes https://github.com/denoland/deno/issues/27062
In the LSP we were passing `npm` specifiers to TSC as roots, but TSC
needs fully resolved specifiers (like the actual file path).
In `deno check` we were often excluding the specifiers entirely from the
roots.
In both cases, we need to resolve the specifiers fully and then pass
them to tsc
Instead of hard erroring, we now surface module not found errors as
TypeScript diagnostics (we have yet to show the source code of the
error, but something we can improve over time).
Support for Wasm modules.
Note this implements the standard where the default export is the
instance (not the module). The module will come later with source phase
imports.
```ts
import { add } from "./math.wasm";
console.log(add(1, 2));
```
* cts support
* better cjs/cts type checking
* deno compile cjs/cts support
* More efficient detect cjs (going towards stabilization)
* Determination of whether .js, .ts, .jsx, or .tsx is cjs or esm is only
done after loading
* Support `import x = require(...);`
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This replaces `--allow-net` for import permissions and makes the
security sandbox stricter by also checking permissions for statically
analyzable imports.
By default, this has a value of
`--allow-import=deno.land:443,jsr.io:443,esm.sh:443,raw.githubusercontent.com:443,gist.githubusercontent.com:443`,
but that can be overridden by providing a different set of hosts.
Additionally, when no value is provided, import permissions are inferred
from the CLI arguments so the following works because
`fresh.deno.dev:443` will be added to the list of allowed imports:
```ts
deno run -A -r https://fresh.deno.dev
```
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
