1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-22 23:34:47 -05:00
Commit graph

107 commits

Author SHA1 Message Date
David Sherret
c497e766f1
refactor: move redirect handling into deno_graph (#23444) 2024-04-19 01:43:28 +00:00
Nayeem Rahman
8e77f091ad
perf(lsp): cleanup document dependencies (#23426) 2024-04-19 00:51:16 +00:00
Igor Zinkovsky
b3d7df5535
perf: v8 code cache (#23081)
This PR enables V8 code cache for ES modules and for `require` scripts
through `op_eval_context`. Code cache artifacts are transparently stored
and fetched using sqlite db and are passed to V8. `--no-code-cache` can
be used to disable.

---------

Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-04-17 07:19:55 -07:00
David Sherret
43c8c1cc6e
feat(check): allow using side effect imports with unknown module kinds (ex. css modules) (#23392)
This allows people to use imports like:

```ts
import "./app.css";
```

...with `deno check` in systems where there's a bundle step (ex. Vite).
This will still error when using it with `deno run` or if the referenced
file does not exist.

See test cases for behaviour.
2024-04-16 16:46:31 -04:00
David Sherret
ade0cd5e97
fix: upgrade deno_ast related crates (#23187)
Had to revert back swc due to
https://github.com/swc-project/swc/issues/8840

Fixes:

- https://github.com/denoland/deno_lint/pull/1262
- https://github.com/denoland/deno_doc/pull/538
- https://github.com/denoland/deno_doc/pull/537
- https://github.com/denoland/deno_graph/pull/430
- https://github.com/denoland/deno_graph/pull/425
- https://github.com/denoland/deno_graph/pull/432
2024-04-11 23:00:17 +00:00
David Sherret
43d066cb70
fix: stop type checking during runtime (#22854)
In addition to the reasons for this outlined by @nayeemrmn in #14877
(which I think are reasons alone to not do this), this simplifies things
a lot because then we don't need to implement the following:

1. Need to handle a JSR module dynamically importing a module within it.
2. Need to handle importing an export of a JSR dep then another export
dynamically loaded later.

Additionally, people should be running `deno check dynamic_import.ts`
instead of relying on this behaviour.

Landing this as a fix because it's blocking people in some scenarios and
the current behaviour is broken (I didn't even have to change any tests
to remove this, which is bad).

Closes #22852
Closes #14877
Closes #22580
2024-03-13 16:38:01 -04:00
David Sherret
594d8397ad
fix(publish): properly display graph validation errors (#22775)
The graph validation errors were displaying cryptically during publish.
This fixes that.
2024-03-07 17:30:30 +01:00
Bartek Iwańczuk
f0ec4fe1b8
fix(publish): silence warnings for sloppy imports and node builtins with env var (#22760)
An undocumented "DENO_DISABLE_PEDANTIC_NODE_WARNINGS" env
var can be used to silence warnings for sloppy imports and node builtins
without `node:` prefix.
2024-03-07 14:59:57 +01:00
cui fliter
d4b3b39cc0
chore: fix typos (#22677) 2024-03-04 14:28:57 +00:00
David Sherret
e9fe71acb5
fix(unstable): sloppy imports should resolve .d.ts files during types resolution (#22602) 2024-02-27 18:30:21 +00:00
David Sherret
190776f30d
perf: linter lsp memory leak fix and deno_graph executor (#22519)
Updates dependent crates which includes an investigation fix by @irbull
in Deno's LSP when linting code. Huge thanks to Ian for tracking down
this issue.

Also includes Divy's deno_graph executor change, which reduces memory
usage when loading jsr specifiers and makes them faster.

Co-authored-by: irbull <irbull@users.noreply.github.com>
Co-authored-by: littledivy <littledivy@users.noreply.github.com>
2024-02-21 21:58:37 +00:00
David Sherret
9166d8a4e9
feat(publish): type check on publish (#22506)
Supersedes #22501 and also fixes that issue.
2024-02-21 08:35:25 -05:00
David Sherret
f90889e5ee
perf(jsr): fast check cache and lazy fast check graph (#22485) 2024-02-20 21:29:57 +00:00
David Sherret
66424032a2
feat(unstable/lint): no-slow-types for JSR packages (#22430)
1. Renames zap/fast-check to instead be a `no-slow-types` lint rule.
1. This lint rule is automatically run when doing `deno lint` for
packages (deno.json files with a name, version, and exports field)
1. This lint rules still occurs on publish. It can be skipped by running
with `--no-slow-types`
2024-02-19 15:28:41 +00:00
David Sherret
828d9b8485
refactor: remove module graph setup from ModuleLoader (#22442)
`ModuleLoader` was doing too much duplicate work.
2024-02-16 22:10:06 +00:00
David Sherret
4f80d83774
feat(unstable): single checksum per JSR package in the lockfile (#22421)
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.
2024-02-15 14:49:35 -05:00
David Sherret
4b7c6049ef
refactor: load bytes in deno_graph (#22212)
Upgrades deno_graph to 0.64 where deno_graph is now responsible for
turning bytes into a string. This is in preparation for Wasm modules.
2024-02-01 03:15:22 +00:00
David Sherret
69d5f136ba
feat(lockfile): track JSR and npm dependencies in config file (#22004)
See overview in https://github.com/denoland/deno_lockfile/pull/13
2024-01-22 22:31:12 +01:00
Bartek Iwańczuk
69959aa01f
fix: update deno_lint and swc (#21718)
Co-authored-by: David Sherret <dsherret@gmail.com>
2024-01-09 23:20:52 +00:00
David Sherret
e212e1fc35
perf: skip expanding exclude globs (#21817)
We were calling `expand_glob` on our excludes, which is very expensive
and unnecessary because we can pattern match while traversing instead.

1. Doesn't expand "exclude" globs. Instead pattern matches while walking
the directory.
2. Splits up the "include" into base paths and applicable file patterns.
This causes less pattern matching to occur because we're only pattern
matching on patterns that might match and not ones in completely
unrelated directories.
2024-01-08 17:18:42 +00:00
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
David Sherret
ddfbe71ced
feat(lsp): provide quick fixes for specifiers that could be resolved sloppily (#21506) 2023-12-08 09:57:06 -05:00
David Sherret
78566753c8
feat: add suggestions to module not found error messages for file urls (#21498) 2023-12-07 15:59:13 -05:00
David Sherret
890780a9e9
feat(unstable): ability to resolve specifiers with no extension, specifiers for a directory, and TS files from JS extensions (#21464)
Adds an `--unstable-sloppy-imports` flag which supports the
following for `file:` specifiers:

* Allows writing `./mod` in a specifier to do extension probing.
- ex. `import { Example } from "./example"` instead of `import { Example
} from "./example.ts"`
* Allows writing `./routes` to do directory extension probing for files
like `./routes/index.ts`
* Allows writing `./mod.js` for *mod.ts* files.

This functionality is **NOT RECOMMENDED** for general use with Deno:

1. It's not as optimal for perf:
https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-2/
1. It makes tooling in the ecosystem more complex in order to have to
understand this.
1. The "Deno way" is to be explicit about what you're doing. It's better
in the long run.
1. It doesn't work if published to the Deno registry because doing stuff
like extension probing with remote specifiers would be incredibly slow.

This is instead only recommended to help with migrating existing
projects to Deno. For example, it's very useful for getting CJS projects
written with import/export declaration working in Deno without modifying
module specifiers and for supporting TS ESM projects written with
`./mod.js` specifiers.

This feature will output warnings to guide the user towards correcting
their specifiers. Additionally, quick fixes are provided in the LSP to
update these specifiers:
2023-12-07 00:03:18 +00:00
David Sherret
a1d823e27d
feat(compile): support discovering modules for more dynamic arguments (#21381)
This PR causes Deno to include more files in the graph based on how a
template literal looks that's provided to a dynamic import:

```ts
const file = await import(`./dir/${expr}`);
```

In this case, it will search the `dir` directory and descendant
directories for any .js/jsx/etc modules and include them in the graph.

To opt out of this behaviour, move the template literal to a separate
line:

```ts
const specifier = `./dir/${expr}`
const file = await import(specifier);
```
2023-12-01 20:12:10 +00:00
Bartek Iwańczuk
9534e6e113
feat(unstable): Workspaces support (#20410)
This commit adds unstable workspace support. This is extremely
bare-bones and
minimal first-pass at this.

With this change `deno.json` supports specifying `workspaces` key, that
accepts a list of subdirectories. Each workspace can have its own import
map. It's required to specify a `"name"` and `"version"` properties in the
configuration file for the workspace:

```jsonc
// deno.json
{
  "workspaces": [
     "a",
     "b"
  },
  "imports": {
    "express": "npm:express@5"
   }
}
```
``` jsonc
// a/deno.json
{
  "name": "a",
  "version": "1.0.2",
  "imports": {
    "kleur": "npm:kleur"
  }
}
```
```jsonc
// b/deno.json
{
  "name": "b",
  "version": "0.51.0",
  "imports": {
    "chalk": "npm:chalk"
  }
}
```

`--unstable-workspaces` flag is required to use this feature:
```
$ deno run --unstable-workspaces mod.ts
```

---------

Co-authored-by: David Sherret <dsherret@gmail.com>
2023-11-17 01:28:38 +00:00
Bartek Iwańczuk
1713df1352
feat: deno run --unstable-hmr (#20876)
This commit adds `--unstable-hmr` flag, that enabled Hot Module Replacement.

This flag works like `--watch` and accepts the same arguments. If
HMR is not possible the process will be restarted instead.

Currently HMR is only supported in `deno run` subcommand.

Upon HMR a `CustomEvent("hmr")` will be dispatched that contains
information which file was changed in its `details` property.

---------

Co-authored-by: Valentin Anger <syrupthinker@gryphno.de>
Co-authored-by: David Sherret <dsherret@gmail.com>
2023-10-31 01:25:58 +01:00
David Sherret
842e29057d
refactor: break out ModuleInfoCache from ParsedSourceCache (#20977)
As title. This will help use the two independently from the other, which
will help in an upcoming deno doc PR where I need to parse the source
files with scope analysis.
2023-10-25 18:13:22 -04:00
David Sherret
be97170a19
feat(unstable): ability to npm install then deno run main.ts (#20967)
This PR adds a new unstable "bring your own node_modules" (BYONM)
functionality currently behind a `--unstable-byonm` flag (`"unstable":
["byonm"]` in a deno.json).

This enables users to run a separate install command (ex. `npm install`,
`pnpm install`) then run `deno run main.ts` and Deno will respect the
layout of the node_modules directory as setup by the separate install
command. It also works with npm/yarn/pnpm workspaces.

For this PR, the behaviour is opted into by specifying
`--unstable-byonm`/`"unstable": ["byonm"]`, but in the future we may
make this the default behaviour as outlined in
https://github.com/denoland/deno/issues/18967#issuecomment-1761248941

This is an extremely rough initial implementation. Errors are
terrible in this and the LSP requires frequent restarts. Improvements
will be done in follow up PRs.
2023-10-25 14:39:00 -04:00
David Sherret
59a5fe530f
refactor: upgrade to deno_ast 0.31 and deno_graph 0.59 (#20965) 2023-10-24 21:43:19 +00:00
Yoshiya Hinosawa
fb73eb1e9d
feat(unstable): allow bare specifier for builtin node module (#20728)
closes #20566
2023-10-20 13:02:08 +09:00
Bartek Iwańczuk
8d9fef3b89
refactor: add WatcherCommunicator helper struct (#20927)
This commit introduces "WatcherCommunicator" struct that
is used facilitate bi-directional communication between CLI
file watcher and the watched function.

Prerequisite for https://github.com/denoland/deno/pull/20876
2023-10-19 07:05:00 +02:00
David Sherret
8d24be1a59
refactor(npm): create cli::npm::managed module (#20740)
Creates the `cli::npm::managed` module and starts moving more
functionality into it.
2023-09-30 12:06:38 -04:00
David Sherret
5edd102f3f
refactor(cli): make CliNpmResolver a trait (#20732)
This makes `CliNpmResolver` a trait. The terminology used is:

- **managed** - Deno manages the node_modules folder and does an
auto-install (ex. `ManagedCliNpmResolver`)
- **byonm** - "Bring your own node_modules" (ex. `ByonmCliNpmResolver`,
which is in this PR, but unimplemented at the moment)

Part of #18967
2023-09-29 09:26:25 -04:00
David Sherret
0709c051f8
feat(unstable): package manager (#20517)
Adds an experimental unstable built-in package manager to Deno, but it is
currently not usable because the registry infrastructure hasn't been
setup and it points to a non-existent url by default. The default
registry url can be configured via the `DENO_REGISTRY_URL` environment
variable.
2023-09-18 10:46:44 -04:00
David Sherret
12a75e3b43
refactor: move deno_core::TaskQueue to cli::util::sync (#20481)
TaskQueue is being removed from `deno_core` and replaced with an unsync
version in deno_unsyc.

https://github.com/denoland/deno_core/pull/193

This is a change in preparation for that. The remaining
`deno_core::TaskQueue` usage in this repo should be replaced with
`deno_core::unsync::TaskQueue` once upgraded.
2023-09-13 21:53:07 +00:00
David Sherret
3fc19dab47
feat: support import attributes (#20342) 2023-09-07 09:09:16 -04:00
David Sherret
c4451d3076
feat(lockfile): add redirects to the lockfile (#20262) 2023-08-29 12:03:02 -05:00
David Sherret
1cefa831fd
feat(unstable): optional deno_modules directory (#19977)
Closes #15633
2023-08-02 00:49:09 +00:00
David Sherret
a8d472f88e
feat(lock): skip saving declaration files in the lockfile (#19447)
This is also a performance improvement because declaration file hashes
don't need to be stored in the lockfile.

Closes #19444
2023-06-26 15:53:17 -04:00
David Sherret
84c793275b
fix: reload config files on watcher restarts (#19487)
Closes #19468
2023-06-14 22:29:19 +00:00
David Sherret
da9db887e3
refactor: helpers methods on TypeCheckMode (#19393) 2023-06-07 10:09:10 -04:00
David Sherret
2aba4365ae
perf(cli): conditionally load typescript declaration files (#19392)
Closes #18583
2023-06-06 17:07:46 -04:00
Nayeem Rahman
b6a3f8f722
refactor(core): remove ext: modules from the module map (#19040)
Rather than disallowing `ext:` resolution, clear the module map after
initializing extensions so extension modules are anonymized. This
operation is explicitly called in `deno_runtime`. Re-inject `node:`
specifiers into the module map after doing this.

Fixes #17717.
2023-05-28 12:44:41 -06:00
David Sherret
cacc8c9a4d
feat: top level package.json install when node_modules dir is explicitly opted into (#19233)
When someone explicitly opts into using the node_modules dir via
`--node-modules-dir` or setting `"nodeModulesDir": true` in the
deno.json file, we should eagerly ensure a top level package.json
install is done on startup. This was initially always done when we added
package.json support and a package.json was auto-discovered, but scaled
it back to be lazily done when a bare specifier matched an entry in the
package.json because of how disruptive it was for people using Deno
scripts in Node projects. That said, it does not make sense for someone
to opt-into having deno control and use their node_modules directory and
not want a package.json install to occur. If such a rare scenario
exists, the `DENO_NO_PACKAGE_JSON=1` environment variable can be set.

Ideally, we would only ever use a node_modules directory with this
explicit opt-in so everything is very clear, but we still have this
automatic scenario when there's a package.json in order to make more
node projects work out of the box.
2023-05-23 18:51:48 -04:00
David Sherret
28aa489de9
feat(compile): unstable npm and node specifier support (#19005)
This is the initial support for npm and node specifiers in `deno
compile`. The npm packages are included in the binary and read from it via
a virtual file system. This also supports the `--node-modules-dir` flag,
dependencies specified in a package.json, and npm binary commands (ex.
`deno compile --unstable npm:cowsay`)

Closes #16632
2023-05-10 20:06:59 -04:00
Nayeem Rahman
3d8a4d3b81
feat(cli): don't check permissions for statically analyzable dynamic imports (#18713)
Closes #17697
Closes #17658
2023-04-26 16:23:28 -04:00
David Sherret
a615eb3b56
refactor(node): move most of cli/node to ext/node (#18797)
This is just a straight refactor and I didn't do any cleanup in
ext/node. After this PR we can start to clean it up and make things
private that don't need to be public anymore.
2023-04-21 21:02:46 -04:00
David Sherret
0a67a3965f
refactor: add TypeChecker struct (#18709)
Adds a `TypeChecker` struct and pushes more shared functionality into
it.
2023-04-14 18:05:46 -04:00
David Sherret
136dce67ce
refactor: break up ProcState (#18707)
1. Breaks up functionality within `ProcState` into several other structs
to break out the responsibilities (`ProcState` is only a data struct
now).
2. Moves towards being able to inject dependencies more easily and have
functionality only require what it needs.
3. Exposes `Arc<T>` around the "service structs" instead of it being
embedded within them. The idea behind embedding them was to reduce the
verbosity of needing to pass around `Arc<...>`, but I don't think it was
exactly working and as we move more of these structs to be more
injectable I don't think the extra verbosity will be a big deal.
2023-04-14 16:22:33 -04:00