A merge conflict is not an error. It is a signal that two branches changed the same lines of the same file, and Git cannot decide which change to keep. The resolution is a human decision, made in the Git working tree, and then committed to the source branch. GitLab’s interface surfaces the conflict, offers…
1. Installation & Upgrade 2. Project Initialization 3. Dependency Management 4. Lockfile & CI Installs 5. Scripts & Binaries 6. Running TypeScript & JSX 7. Bun APIs (bun:sqlite, Bun.serve) 8. File System (Bun.file, Bun.write) 9. Test Runner (bun:test) 10. Bundling (bun build) 11. CI/CD (GitHub Actions) 12. Trusted Dependencies (Lifecycle Scripts) 13. Migration from Node.js…
Bun is designed as a drop-in replacement for Node.js, and most projects migrate with command substitutions rather than code rewrites . The migration is not all-or-nothing: a project can adopt bun install for speed while continuing to run under Node.js, then switch the runtime when compatibility is verified. The exam tests the command mapping, the…
Bun’s CI/CD story is built on a single command: bun install –frozen-lockfile. The flag ensures the lockfile is respected and never rewritten during the install. Unlike pnpm, which has a separate –offline mode that requires pre-populated caches, Bun’s approach to reproducibility is simpler: the lockfile is the contract, and the global cache is the optimization….
Bun’s bundler is not a separate tool. It is a component of the runtime, exposed through the bun build command and the Bun.build() JavaScript API. The bundler reads TypeScript, JSX, and CSS natively, resolves imports using Bun’s own resolver, and produces optimized output for a specified target. The LFCS exam does not test Bun, but…
Bun ships with a built-in test runner, and it is not a wrapper around Jest or Vitest. The bun:test module is implemented in the runtime and executed by Bun itself. This means TypeScript and JSX test files run without a transpilation step, the startup cost is eliminated, and the runner is significantly faster than Jest—benchmarks…
The previous chapters configured the SSH server and client for direct connections. This chapter covers the mechanisms that route traffic through an SSH connection to reach services that are otherwise inaccessible. SSH tunneling, also called port forwarding, creates an encrypted channel between the client and the server, and then relays traffic through that channel to…
The previous chapter deployed the public key to the server’s authorized_keys. This chapter covers two client-side mechanisms that make key-based authentication practical at scale: the SSH agent, which caches decrypted private keys in memory so the passphrase is typed once per session, and the SSH config file, which stores per-host connection settings so the command…
The previous chapters configured the SSH server to accept key-based authentication and reject passwords. This chapter covers the client side: generating a key pair, deploying the public key to the server’s authorized_keys file, and fixing the permission errors that cause key authentication to fail silently. The LFCS exam tests the workflow and the specific permission…
The previous chapter established the configuration syntax and the lockout risk. This chapter covers the directives that reduce the attack surface after the basic setup is working. Hardening is not a single change but a layered strategy: eliminate the most attractive attack vectors (root login, password authentication), reduce the window for brute force (MaxAuthTries, LoginGraceTime),…