1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-26 16:09:27 -05:00
Commit graph

2 commits

Author SHA1 Message Date
Bartek Iwańczuk
b1c6142f74
BREAKING: DENO_FUTURE=1 by default, or welcome to Deno 2.0 (#25213)
This commit effectively turns Deno into Deno 2.0.

This is done by forcing `DENO_FUTURE=1` env var, that was available in
the past few months to try Deno 2 changes.

This commit contains several breaking changes scheduled for Deno 2:
- all deprecated JavaScript APIs are not available any more, mostly
`Deno.*` APIs
- `window` global is removed
- FFI, WebGPU and FS APIs are now stable and don't require
`--unstable-*` flags
- import assertions are no longer supported
- "bring your own node modules" is enabled by default

This is the first commit in a series that are scheduled before the Deno
2 release.

Follow up work is tracked in
https://github.com/denoland/deno/issues/25241.

---------

Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
Co-authored-by: Nathan Whitaker <nathan@deno.com>
2024-08-30 13:58:58 -04:00
Nathan Whitaker
5de30c5323
fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile (#23918)
Fixes #23571.

Previously, we required a `deno.json` to be present (or the `--lock`
flag) in order for us to resolve a `deno.lock` file. This meant that if
you were using deno in an npm-first project deno wouldn't use a
lockfile.

Additionally, while I was fixing that, I discovered there were a couple
bugs keeping the future `install` command from using a lockfile.

With this PR, `install` will actually resolve the lockfile (or create
one if not present), and update it if it's not up-to-date. This also
speeds up `deno install`, as we can use the lockfile to skip work during
npm resolution.
2024-05-23 12:31:05 -07:00