mirror of
https://github.com/denoland/deno.git
synced 2024-12-31 11:34:15 -05:00
890780a9e9
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:
|
||
|---|---|---|
| .. | ||
| args | ||
| bench | ||
| cache | ||
| js | ||
| lsp | ||
| napi | ||
| npm | ||
| ops | ||
| schemas | ||
| standalone | ||
| tests | ||
| tools | ||
| tsc | ||
| util | ||
| auth_tokens.rs | ||
| build.rs | ||
| Cargo.toml | ||
| cdp.rs | ||
| deno.ico | ||
| deno_std.rs | ||
| emit.rs | ||
| entitlements.plist | ||
| errors.rs | ||
| factory.rs | ||
| file_fetcher.rs | ||
| graph_util.rs | ||
| http_util.rs | ||
| js.rs | ||
| main.rs | ||
| module_loader.rs | ||
| node.rs | ||
| README.md | ||
| resolver.rs | ||
| version.rs | ||
| worker.rs | ||
Deno CLI Crate
This provides the actual deno executable and the user-facing APIs.
The deno crate uses the deno_core to provide the executable.