This slightly degrades the performance of CJS export analysis on
subsequent runs because I changed it to no longer cache in the DENO_DIR
with this PR (denort now properly has no idea about the DENO_DIR). We'll
have to change it to embed this data in the binary and that will also
allow us to get rid of swc in denort (will do that in a follow-up PR).
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
Fixes https://github.com/denoland/deno/issues/25762. Note that some of
the things in that issue are not resolved (vite/client types not working
properly which has other root causes), but the wildcard module
augmentation specifically is fixed by this.
We were telling TSC that files with unknown media types had an extension
of `.js`, so the ambient module declarations weren't applying. Instead,
just don't resolve them, so the ambient declaration applies.
Working on loading plugin configuration for
https://github.com/denoland/deno/pull/27203
I encountered a lot of complexity, so did some drive-by cleanups to make
it easier to grok the code and have fewer duplicate names.
Currently deno eagerly caches all npm packages in the workspace's npm
resolution. So, for instance, running a file `foo.ts` that imports
`npm:chalk` will also install all dependencies listed in `package.json`
and all `npm` dependencies listed in the lockfile.
This PR refactors things to give more control over when and what npm
packages are automatically cached while building the module graph.
After this PR, by default the current behavior is unchanged _except_ for
`deno install --entrypoint`, which will only cache npm packages used by
the given entrypoint. For the other subcommands, this behavior can be
enabled with `--unstable-npm-lazy-caching`
Fixes #25782.
---------
Signed-off-by: Nathan Whitaker <17734409+nathanwhit@users.noreply.github.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
Fixes https://github.com/denoland/deno/issues/27289
We exported these but forgot to add them to the list of builtins used by
the resolver, so we weren't resolving bare imports of some modules (e.g.
`"_http_common"`)
Also adds a missing export of `HTTPParser` from `_http_common`
This was doing an allocation for reparsing the specifier. Might as well
do `.join` here and it means I can extract out this file fetcher code to
deno_cache_dir more easily.
This commit adds support for understanding "workpace:^"
and "workspace:~" version constraints in npm/pnpm workspaces.
This is done by upgrading various crates to their latest versions.
Closes https://github.com/denoland/deno/issues/26726
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
This resurrects the `--unstable-detect-cjs` flag (which became stable),
and repurposes it to attempt loading .js/.jsx/.ts/.tsx files as CJS in
the following additional scenarios:
1. There is no package.json
1. There is a package.json without a "type" field
Also cleans up the implementation of this in the LSP a lot by hanging
`resolution_mode()` off `Document` (didn't think about doing that until
now).
Ensures a dynamic import in a CJS file will consider the referrer as an import for node resolution.
Also adds fixes (adds) support for `"resolution-mode"` in TypeScript.
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));
```
This commit changes three aspects of `deno task`:
1. Tasks can now be written using object notation like so:
```jsonc
{
"tasks": {
"foo": "deno run foo.js",
"bar": {
"command": "deno run bar.js"
}
}
```
2. Support for comments for tasks is now removed. Comments above tasks
will
no longer be printed when running `deno task`.
3. Tasks written using object notation can have "description" field that
replaces
support for comments above tasks:
```jsonc
{
"tasks": {
"bar": {
"description": "This is a bar task"
"command": "deno run bar.js"
}
}
```
```
$ deno task
Available tasks:
- bar
// This is a bar task
deno run bar.js
```
Pulled most of the changes from
https://github.com/denoland/deno/pull/26467 to
support "dependencies" in tasks. Additionally some cleanup was performed
to make code easier to read.
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
