new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Deno · Reference · all subjects

cli commands/compile

39 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

deno compile --app-name storage behavior

Because the app name (not the module path) drives the storage directory: the store stays stable across runs even if you rename the binary; two binaries built with the same --app-name share a store; differently named apps stay isolated; and recompiling with a different --app-name starts a fresh store.

deno compile basic usage

The deno compile command compiles TypeScript/JavaScript code into a standalone executable. Runtime flags and permission flags must be specified at compilation time.

deno compile with script arguments

Script arguments can be partially embedded in the compilation command. For example, deno compile --allow-read --allow-net jsr:@std/http/file-server -p 8080 embeds the -p 8080 argument, and the resulting executable can be run with additional arguments like ./file_server --help.

deno compile framework detection

Starting in Deno 2.8, deno compile . or deno compile <directory> detects common web frameworks and produces an appropriate entrypoint. Supported frameworks are: Next.js, Astro, Fresh (1.x and 2.x), Remix, React Router, SvelteKit, Nuxt, SolidStart, TanStack Start, and Vite (SSR, plus SPA/MPA projects served as static output). The detected build script is run first, ensuring the compiled binary contains a fresh build.

deno compile framework detection with app directory

When compiling a web framework project, you can point deno compile at a specific app directory using deno compile ./apps/web.

deno compile framework entrypoint and asset paths

Generated entrypoints for frameworks use import.meta.dirname so framework asset paths resolve correctly against the virtual filesystem inside the compiled binary.

deno compile React Router requirements

React Router projects must build successfully under Deno before they can be compiled. Because React Router's default server entry targets Node.js, you must add a Web Streams-compatible app/entry.server.tsx when building with Deno.

deno compile watch mode

Pass --watch to rebuild the executable whenever a file in the compile graph changes.

deno compile watch mode exclusion and output control

Use --watch-exclude to keep specific paths from triggering a rebuild, and --no-clear-screen to preserve the terminal output between rebuilds. Example: deno compile --watch --watch-exclude=./dist --no-clear-screen main.ts

deno compile cross-compilation with --target flag

Cross-compile binaries for other platforms using the --target flag. For example: deno compile --target aarch64-apple-darwin main.ts for Apple Silicon, or deno compile --target x86_64-pc-windows-msvc --icon ./icon.ico main.ts for Windows with an icon.

deno compile supported cross-compilation targets

Deno supports cross-compiling to all targets regardless of the host platform. Supported targets: Windows x86_64 (x86_64-pc-windows-msvc), Windows ARM64 (aarch64-pc-windows-msvc, supported from Deno 2.9.3), macOS x86_64 (x86_64-apple-darwin), macOS ARM64 (aarch64-apple-darwin), Linux x86_64 (x86_64-unknown-linux-gnu), Linux ARM64 (aarch64-unknown-linux-gnu).

deno compile denort binary

deno compile embeds your program into denort ('Deno runtime'), a stripped build of Deno containing only what is needed to run a compiled program, with none of the tooling subcommands. This keeps compiled executables smaller than using the full deno binary.

deno compile denort caching and download

The first time you compile for a given Deno version and target, Deno downloads the matching denort-<target>.zip from dl.deno.land and caches it in DENO_DIR. Subsequent compiles reuse the cached binary and work offline. Cross-compilation works by fetching that platform's denort.

deno compile custom runtime with DENORT_BIN

To use a custom or locally built runtime as the base, set the DENORT_BIN environment variable to its path. Deno also picks up a denort binary placed next to the deno executable.

deno compile --engine flag for QuickJS

The --engine flag lets you choose between v8 (default) and quickjs JavaScript engines. The --engine quickjs flag is experimental and subject to change; it landed after Deno 2.9.4 and is available in canary builds and later releases.

deno compile v8 and QuickJS engine examples

Compiled binaries run on V8 by default. Examples: deno compile --engine v8 main.ts (default, same as omitting the flag), or deno compile --engine quickjs main.ts to build a binary that runs on QuickJS.

deno compile QuickJS trade-offs

QuickJS trade-offs include: Security updates—QuickJS does not receive the same security updates as V8; do not use it for programs that run untrusted input. Performance—QuickJS is an interpreter with no JIT, so compute-heavy code runs slower than on V8, but startup and memory use are lower. Maturity—The backend is experimental; behavior differences from V8 are possible, so test your program with the intended engine.

deno compile QuickJS runtime downloads

With --engine quickjs, Deno downloads denort-quickjs-<target>.zip (or libdenort-quickjs-<target>.zip for deno desktop) instead of the default denort-<target>.zip. Both variants are published for every supported target, so cross-compilation works the same way.

deno compile QuickJS with custom runtime

If you override the base runtime with DENORT_BIN or a denort binary next to deno, that binary is used as-is: --engine is then ignored and Deno prints a warning.

deno compile --icon flag for Windows

Add an icon to the executable by using the --icon flag when targeting Windows. The icon must be in .ico format. Examples: deno compile --icon icon.ico main.ts, or deno compile --target x86_64-pc-windows-msvc --icon ./icon.ico main.ts for cross-compilation with an icon.

deno compile static dynamic imports

By default, statically analyzable dynamic imports (imports with a string literal within the import(...) call expression) will be included in the output. For example, const calculator = await import('./calculator.ts'); will include calculator.ts and its dependencies in the binary.

deno compile non-static dynamic imports

Non-statically analyzable dynamic imports will not be included by default. For example, const specifier = condition ? './calc.ts' : './better_calc.ts'; const calculator = await import(specifier); will not include those modules. To include them, specify an --include <path> flag for each file.

deno compile --include for non-static dynamic imports

To include non-statically analyzable dynamic imports, specify an --include <path> flag for each module. Example: deno compile --include calc.ts --include better_calc.ts main.ts

deno compile --include for data files and directories

Starting in Deno 2.1, you can include files or directories in the executable by specifying them via the --include <path> flag. Example: deno compile --include names.csv --include data main.ts

deno compile reading included files with import.meta.dirname

Read included files relative to the directory path of the current module via import.meta.dirname. Example code: const names = Deno.readTextFileSync(import.meta.dirname + '/names.csv'); const dataFiles = Deno.readDirSync(import.meta.dirname + '/data');

deno compile --include-as-is for pre-built bundles

To embed files exactly as they are without any module resolution, use --include-as-is instead of --include. This is the right choice for pre-built frontend bundles (for example Vite or webpack output) that are already processed and would fail to resolve as Deno modules. Example: deno compile --include-as-is ./dist main.ts

deno compile workers inclusion

Code for workers is not included in the compiled executable by default. There are two ways to include workers: 1. Use the --include <path> flag to include the worker code, or 2. Import worker module using a statically analyzable import.

deno compile workers with --include flag

Include worker code using the --include flag. Example: deno compile --include worker.ts main.ts

deno compile workers with static import

Include worker code by importing the worker module using a statically analyzable import. Example: in main.ts, add import './worker.ts'; and then run deno compile main.ts

deno compile --self-extracting flag

By default, compiled executables serve embedded files from an in-memory virtual file system. The --self-extracting flag changes this behavior so that the binary extracts all embedded files to disk on first run and uses real file system operations at runtime. Example: deno compile --self-extracting main.ts

deno compile --self-extracting extraction directory preference

The extraction directory is chosen in order of preference: 1. <exe_dir>/<exe_name>/<hash>/ (next to the compiled binary), 2. Platform data directory fallback: Linux: $XDG_DATA_HOME/<exe_name>/<hash> or ~/.local/share/<exe_name>/<hash>, macOS: ~/Library/Application Support/<exe_name>/<hash>, Windows: %LOCALAPPDATA%\<exe_name>\<hash>

deno compile --self-extracting file extraction behavior

Files are only extracted once. Subsequent runs reuse the extracted directory if it already exists and the hash matches.

deno compile --self-extracting trade-offs

Self-extracting mode enables broader compatibility but comes with trade-offs: Initial startup cost—first run takes longer due to file extraction. Disk usage—extracted files take up additional space. Memory usage—higher memory usage since embedded content can no longer be referenced as static data. Tamper risk—users or other code can modify the extracted files on disk.

deno compile code signing on macOS

By default on macOS, the compiled executable will be signed using an ad-hoc signature, equivalent to running codesign -s -. You can specify a signing identity when code signing the executable just like any other macOS executable using codesign -s 'Developer ID Application: Your Name' ./main

deno compile macOS ad-hoc code signing example

Example of verifying ad-hoc signed code: deno compile -o main main.ts, then codesign --verify -vv ./main should show './main: valid on disk' and './main: satisfies its Designated Requirement'

deno compile code signing on Windows

On Windows, the compiled executable can be signed using the SignTool.exe utility. Example: deno compile -o main.exe main.ts, then signtool sign /fd SHA256 main.exe

deno compile persistent storage in executables

A compiled binary is treated as a standalone application, so origin-bound storage persists across runs in the platform's application data directory (%LOCALAPPDATA% on Windows, ~/Library/Application Support on macOS, $XDG_DATA_HOME on Linux). localStorage, Web Cache API, and Deno.openKv() called without a path use this directory.

deno compile --app-name flag

The --app-name flag sets the identity of a compiled app, which is baked in at compile time and falls back to the output file name when omitted. Each compiled app gets its own storage location derived from its identity. Example: deno compile --app-name my-app main.ts

deno compile command

deno compile is used to compile a program into a standalone executable.

Give your agent this brain