DEV Community: Patrick Organ

Developer Tooling #008

Patrick Organ — Thu, 20 Nov 2025 17:35:15 +0000

Developer Tooling #008

Welcome to Developer Tooling #008, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering, Laravel, PHP, and other related topics.

This month we're covering code editors and IDEs.

Zed

Zed is a free, open source, Rust-native code editor with GPU-accelerated rendering, built-in LSP and Tree-sitter, debugger, Git, remote development, AI assistance, and real-time multiplayer editing.

what we like: very fast native UI; first-class multiplayer collaboration built in; strong integrated AI features (assistant panel, agentic editing, edit prediction, custom models like Zeta, MCP support); solid remote development and multibuffer workflows; modern Rust codebase that feels future proof.
what we don't like: ecosystem and extension catalog are still small compared to VS Code; some collaboration and AI capabilities depend on Zed cloud services and GitHub sign-in; freemium limits on predictive edits and AI usage; product is evolving quickly, so workflows and UX can shift under you.

Visual Studio Code

Visual Studio Code (VSCode) is Microsoft’s cross-platform, Electron-based editor with an IDE feel, a huge extension ecosystem, integrated debugger, Git and terminal support, and deep AI integration through GitHub Copilot and related tooling.

what we like: ubiquitous and battle tested; enormous extension marketplace for almost every language and framework; excellent debugging, Git integration, and remote development (SSH, containers, WSL, Codespaces); strong Copilot and AI Toolkit integration; great documentation and community coverage for nearly any stack.
what we don't like: Electron footprint plus heavy extension setups can make it slow and memory hungry; telemetry and licensing are more complex than a pure FOSS editor; configuration surface area is huge and easy to over customize into fragility; advanced AI features are increasingly tied to paid Microsoft and GitHub offerings.

Antigravity

Antigravity is Google’s new agent-first IDE, built as a fork of VS Code and tightly integrated with Gemini 3 Pro and other models. It lets autonomous AI agents plan, edit, run, and verify code directly inside the editor, terminal, and browser, producing verifiable artifacts like task plans, diffs, screenshots, and recordings.

what we like: designed around multi agent workflows from day one, with a Manager view that feels like mission control for your AI workers; clear verification model via artifacts instead of opaque tool call logs; multi model support across Gemini, Claude, and open models; familiar VS Code style editor so existing shortcuts and habits mostly transfer; currently free public preview with generous rate limits, which makes it low friction to evaluate.
what we don't like: very early preview so there are rough edges, missing integrations, and potential instability; agents with terminal and browser control raise security and governance questions for serious teams; future pricing and licensing are unknown; extension compatibility and long term ecosystem story are not fully clear yet; switching from direct coding to agent management is a nontrivial mindset shift and will not fit every developer.

Lapce

Lapce is a modern, open source code editor written in Rust with a native GPU accelerated UI, built-in LSP, Tree-sitter based syntax highlighting, remote development, Vim style modal editing, and a WASI based plugin system.

what we like: very fast native experience with snappy startup and input; GPU rendering and Rust core give it good performance headroom; remote development is built in and can be paired with the Lapdev platform; first class Vim like modal editing with no plugins required; WASI plugin architecture allows writing extensions in any language that compiles to WASI; open source and community driven.
what we don't like: plugin ecosystem is still relatively small compared to VS Code; UI and UX are more minimal and can feel less polished; some workflows require manual configuration and lack a smooth out of the box experience; smaller community means fewer guides and integrations for niche stacks.

Pulsar

Pulsar is a community led, hyper hackable text editor that continues the Atom lineage, with cross platform support, a built-in package manager, and IDE like language server integrations.

what we like: essentially keeps the Atom experience alive with active community maintenance; leverages a large existing ecosystem of Atom and Pulsar packages and themes; very customizable through familiar web technologies like JavaScript, HTML, and CSS; solid Git integration, multi pane layout, and file tree make it a comfortable general purpose editor.
what we don't like: Electron base means higher resource usage and slower performance on very large projects; AI and agentic workflows are mostly add ons through third party packages rather than a core focus; roadmap and sustainability depend on volunteer community capacity; some older Atom era packages are unmaintained or flaky.

Cursor

Cursor is an AI first IDE forked from VS Code, focused on repo scale understanding, powerful autocomplete, inline edits, and agent like workflows, with features like smart rewrite, project wide refactors, integrated chat, and Bugbot for automated debugging.

what we like: tight AI integration across the editor with multiple levels of autonomy, from small inline edits to large refactors; strong codebase indexing that lets AI operate on the whole repository, not just the current file; good UX for exploratory or vibe coding and for PR review, with integrations into services like GitHub and Slack; Bugbot style automated debugging that can surface subtle logic or security issues; still close enough to VS Code that most keybindings and workflows carry over.
what we don't like: proprietary and subscription based, with higher costs at heavier usage tiers; heavy reliance on remote services and code indexing that some organizations will reject on security or compliance grounds; AI centric workflow can encourage over reliance on generated code if teams are not disciplined; extension ecosystem is narrower than stock VS Code and tied to Cursor’s release cadence and choices.

Developer Tooling #007

Patrick Organ — Sat, 18 Oct 2025 00:17:03 +0000

Welcome to Developer Tooling #007, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering, Laravel, and related topics.

This edition's theme is linting of all types!

hadolint
Description: Dockerfile linter, validate inline bash, written in Haskell.
What we like: Well-maintained over the long term, active development, works very well. A true 12-factor application - can even be configured via environment vars!
What we don't like: No JSON output.
Extras: Lint Dockerfiles online
ruff
Description: An extremely fast Python linter and code formatter, written in Rust.
What we like: Orders of magnitude faster than other Python linters, very active development.
What we don't like: Still a zero-point release (0.14 as of this article), which allows for breaking changes in minor and patch releases.
actionlint
Description: Static checker for GitHub Actions workflow files.
What we like: Lints workflow files, an area lacking much tooling. Actively developed.
What we don't like: Docs are a bit outdated.
dotenv-linter
Description: ⚡️Lightning-fast linter for .env files. Written in Rust.
What we like: Highly active development. Stable.
What we don't like: Documentation leaves something to be desired.
typos
Description: Check source code for typos.
What we like: Make sure your source code doesn't have typographical errors.
What we don't like: Doesn't have an option for custom dictionaries.

Developer Tooling #006

Patrick Organ — Sat, 13 Sep 2025 08:53:05 +0000

Welcome to Developer Tooling #006, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering and related fields. If you haven't checked out his newsletter, take the time to now. It's worth it.
For this edition, we're experimenting with a themed approach for all of the showcased tools. Please let us know if you prefer it (or not!)

Theme: ECMAScript/TypeScript native-binary bundlers & compilers (built with Go, Rust, etc.)

rspack
Description: A modern, rust-based javascript compiler that replaces webpack.
What we like: Rich feature set that attempts to have feature parity with webpack; it's part of a growing ecosystem that appears well-maintained.
What we don't like: It supports similar complexity in its configuration due to feature parity with webpack
esbuild
Description: a Javascript/TypeScript/React compiler written in Go.
What we like: It's the OG compiler/bundler for JS/TS. It was orders of magnitude faster than anything else before it was cool.
What we don't like: It's lost some ground to tools such as bun.
bun
Description: A feature-rich, extremely fast bundler, compiler, and package manager all in one.
What we like: it's incredibly fast not only when bundling, but also as an NPM replacement - it's working on feature parity with the npm cli and API; bun install is so much faster than npm it's hard to believe.
What we don't like: It's written in Zig, which may have been a poor choice for long-term maintainability.
rolldown
Description: A rust-based tool that aims to replace rollup.
What we like: Highly active development. Aims to replace rollup, which is too slow.
What we don't like: Documentation leaves something to be desired (it's not bad, but it could be better)
farm
Description: Another rust-based bundler
What we like: Excellent documentation; has been under active development for quite some time; if its history is a reliable indicator, it will (hopefully) be reliably maintained for years to come.
What we don't like: The speed comparisons on their website feel dishonest - we don't like that it claims to be faster than everything but doesn't offer direct comparisons for tools like bun. (Note: we're not commenting on the accuracy of their comparisons - only noting that the comparisons aren't presented in the best light)

Developer Tooling #005

Patrick Organ — Tue, 19 Aug 2025 18:20:31 +0000

Welcome to Developer Tooling #005, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering and related fields. If you haven't checked out his newsletter, take the time to now. It's worth it.

openreplay
Description: Session replay, cobrowsing and product analytics
What we like: Rich feature set, maintained, and excellent documentation
What we don't like: Infrequent releases
difftastic
Description: a structural diff that understands syntax
What we like: simple and strightforward, integrates with git
What we don't like: Currently has zero-point versions, allowing breaking changes between versions
task
Description: A task runner / simpler Make alternative written in Go
What we like: it "just works", in our experience
What we don't like: Task definitions can get long and difficult to read
TruffleHog
Description: Find, verify, and analyze leaked credentials
What we like: Plenty of features; frequent releases
What we don't like: PRs and issues on GH aren't always reviewed in a timely manner.
fnm
Description: Fast and simple Node.js version manager, built in Rust
What we like: faster and easier to use than nvm
What we don't like: Repository readme could be more extensive.

Developer Tooling #004

Patrick Organ — Thu, 24 Jul 2025 07:21:16 +0000

Welcome to the fourth edition of Developer Tooling, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering and related fields.

ots | Github

What it does: Share end-to-end encrypted secrets with others via a one-time URL.
What we like: Feature-complete, secure.
What we don't like: no GUI option.

yazi | Github

What it does: Blazing fast terminal file manager written in Rust, based on async I/O.
What we like: Feature-complete, regular commits.
What we don't like: Some features seem to be overkill for a terminal-based file manager.

dive | Github

What it does: A tool for exploring each layer in a docker image.
What we like: Extremely useful for reducing docker image sizes; easy to use.
What we don't like: no command-line arguments to automatically analyze the images (must be done using the TUI).

aider | Github

What it does: AI code assistant in your terminal.
What we like: Works well, can connect to most hosted models via API, and supports the top models by default.
What we don't like: Under heavy development (over 12k commits), zero-point release means breaking changes are possible.

Developer Tooling #003

Patrick Organ — Tue, 24 Jun 2025 16:27:21 +0000

Welcome to the third edition of Developer Tooling, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering and related fields.

delta | Github

What it does: A syntax-highlighting pager for git, diff, grep, and blame output
What we like: Feature-complete, highly customizable.
What we don't like: Appears to be in maintainance mode instead of active development.

act | Github

What it does: Run your GitHub Actions locally.
What we like: Test your GitHub workflows locally.
What we don't like: Still a zero-point release, so breaking changes are possible for any release.

actionlint | Github

What it does: Static checking for GitHub workflows.
What we like: Lint your workflow files.
What we don't like: Last release was 6 months ago.

dotenv-linter | Github

What it does: Lints .env files.
What we like: Fast.
What we don't like: Appears to not longer be under development, last release was 3 years ago.

Developer Tooling #002

Patrick Organ — Thu, 22 May 2025 23:45:06 +0000

Welcome to Developer Tooling #002! Each month, we provide a few tooling links geared towards modern, advanced developers and engineers.

hygen
Description: simple, fast, scalable code generator
What we like: easily scaffold custom projects
What we don't like: seems to be in maintenance mode without new updates or features.
super-productivity
Description: simple time/task tracker
What we like: simple and strightforward, has a web client
What we don't like: the UX needs work.
thecolorapi
Description: fast, modern, swiss army knife for color
What we like: easily work with colors and palettes
What we don't like: neat features, but the UX is lacking.
nitro
Description: Next generation server toolkit
What we like: easily build http servers
What we don't like: PRs and issues on GH aren't managed in a timely manner.
ots
Description: share secrets with one-time links
What we like: easily & securely share passwords
What we don't like: Repository readme is lacking.

Developer Tooling #001

Patrick Organ — Fri, 25 Apr 2025 13:46:35 +0000

Welcome to the first edition of Developer Tooling, a newsletter enhancement for Freek Van der Herten's popular and high-quality newsletter, geared towards Software Engineering and related fields.

TerraCognita | Github

What it does: Generate infra-as-code for Terraform based on your existing cloud configuration and services.
What we like: Supports the most popular providers: AWS, Azure, and GCP.
What we don't like: Lower activity based on git history - perhaps this is a great project to fork!

frp | Github

What it does: Provides a feature-complete reverse proxy.
What we like: Supports TCP, UDP, and HTTP/S protocols.
What we don't like: Appears to require extensive configuration due to the number of features and options.

LlamaOCR | Github

What it does: Converts text in images to markdown documents using Llama 3.2.
What we like: OCR for receipts? Yes, please!
What we don't like: Limited commit history, not under heavy/active development.

fnm | Github

What it does: Like nvm, but written in Rust; manages your installed node.js versions.
What we like: Significant speed compared to nvm.
What we don't like: Documentation is a bit lacking.

From Contributor to Maintainer: Lessons from Open Source Software

Patrick Organ — Mon, 24 Jun 2024 06:12:54 +0000

Since I started focusing on contributions to open-source projects a few years ago, I’ve opened and had merged hundreds of Pull Requests. This article outlines some of the lessons I've learned from contributing to, authoring, and maintaining popular open-source projects.

Creating Open Source Projects

Avoid creating projects that you cannot or will not maintain. Open-source projects require ongoing attention to address issues, update dependencies, and incorporate new features. If you do not have the capacity or commitment to maintain a project, it is better not to release it to the public.

Your code should be easily understood and be maintainable by others. Clear documentation, consistent coding standards, and well-organized codebases are essential when introducing an open source project. This not only facilitates collaboration but also ensures that others can step in to help with maintenance or contribute new features.

Avoid creating packages that are too specific. The more generalized and flexible your project, the broader its appeal and utility to the community. By focusing on creating versatile and widely applicable projects, you can attract a larger base of users and contributors.

Automate everything. To streamline the maintenance and management of your projects, use of GitHub workflows and features like Dependabot whenever you can. Automating processes such as merging Dependabot PRs, running test suites, marking issues as stale, and updating the changelog can significantly reduce the manual workload. These tools ensure that your project remains up-to-date and stable without constant manual intervention.

Contributing to Open Source Projects

Target projects that you use frequently. Familiarity with the functionality and nuances of it puts you in a position to provide meaningful features or fixes. Whether squashing bugs that you’ve discovered or implementing features you have use cases for, your contributions will likely address needs that others have also encountered.

Your contributions are public and are a reflection on you as an engineer. Remember that potential employers may look at your previous work. It's important to think carefully about the quality and thoroughness of your contributions; each pull request you make is a demonstration of your abilities and your understanding of software development. By consistently contributing well-structured, tested, and documented code, you not only support the projects you care about but also build a strong professional reputation that can open doors to future opportunities.

Open thoughtful pull requests. The clarity and thoroughness of your PR descriptions make a significant difference in whether or not it gets merged quickly, slowly, or at all. Start by summarizing what the pull request does in a few sentences, then drill down into the important points below. This approach not only helps maintainers understand the scope and purpose of your changes quickly, but also facilitates a timely, smooth review process.

Keep your pull requests small and focused. Each PR should add a single feature or fix a single bug. This streamlines the review process for maintainers, enabling them to review and merge your code more quickly. Likewise, it’s also easier to address any requested changes promptly. A small, well-defined PR is less likely to introduce unintended side effects and is generally easier to test and validate.

Include unit tests. Responsible maintainers will rarely merge code without appropriate tests, as they help ensure that new changes do not break existing functionality. By including unit tests with your Pull Request, you’re respecting the maintainers' time and reduce the back-and-forth that can occur when tests are missing. Even if your PR seems trivial or is already covered by existing tests, demonstrating that you've thought about testing can expedite the merge process and reflect positively on your contributions.

Update documentation when you make API changes. If the project you’re contributing to has existing documentation, remember that someone took the time to write it; respect this effort on their part and make sure you update it accordingly, including using a similar tone and style. This ensures that other developers can understand and effectively use the new or modified features you have implemented. Neglecting this step can lead to confusion, undermining the usability and reliability of the project.

Respect the time and effort of maintainers and contributors. You’re a user of the project and have benefited from the time and effort of others. Acknowledge the hard work and dedication when you can. Demonstrating appreciation and respect allows you to receive it in return. Always be considerate and courteous.

Respect existing code and writing styles. Remember that this isn’t your project - it’s someone’s, though, and their preferences matter. Whether it’s two spaces for indentation instead of four (or even - gasp - tabs), or the writing style of the documentation, show the original author the respect of using their style preferences.

Maintaining Open Source Projects

It’s a privilege, not a right. Being a maintainer and having the ability to triage issues, review and merge Pull Requests and release new versions is a privilege, not a right. This role comes with significant responsibility and trust, and should be approached seriously. Your actions as a maintainer can directly impact the quality and reliability of a project; they will also affect the experience of the project’s users. Likewise, your actions can impact the reputation of others, such as the original project author. Be mindful of this.

Get input from others. When uncertain about how to address an issue or handle a pull request, don’t hesitate to seek input from other maintainers. Collaboration and communication are key to making well-informed decisions that benefit the project and its community. Leveraging the collective knowledge and experience of others helps ensure that the best possible solutions are used.

Be appreciative. A simple thank you to a contributor or author of a bug report can go a long way. Recognizing the efforts of others not only strengthens open source community but also motivates continued contributions and engagement in the project.

If you're interested, check out some of my open source contributions in my GitHub Organization or my GitHub profile.

Follow-up edit - See this fantastic response article by Tom Herrmann. It's very well written and reasoned out, and it's worth a read. Thanks, Tom!

Mastering NPM Library Creation: Bundling with Vite

Patrick Organ — Sun, 03 Mar 2024 00:21:53 +0000

If you're writing a library to publish on NPM, there are several options for bundling (building) the library files. The number of options can be confusing, so this article will cover a popular choice for advanced library bundling, Vite.

I won't be covering use of the CLI for bundling, instead we'll cover more complex build configurations using a NodeJS build script that leverages the API provided by Vite.

We'll be bundling a new version of one of my NPM libraries, node-ray. It's written in TypeScript, has two entry points (one for NodeJS and one for browser use), and builds six library files: ESM and CommonJS format for the two entry point files, as well as a "standalone" version that bundles all of the dependencies to allow importing it into a webpage via a CDN (the standard builds exclude all dependencies in the final bundles).

Building with Vite

Vite is a modern build tool that provides a great development experience with features like ultra-fast build times (thanks to ESBuild) and Hot Module Reloading (HMR). While HMR might not be a necessity for library development, it's a boon for projects such as React component libraries, enhancing the development flow.

First, install the vite package into your project's development dependencies:

npm install vite -D

Let's go through each section of the build script individually.

Imports: not much to say here.

import { readFile } from 'node:fs/promises';
import { dirname, resolve } from 'node:path';
import { fileURLToPath } from 'node:url';
import { defineConfig, build as viteBuild } from 'vite';

Following the imports, we introduce a global configuration object, a central location for all configurable aspects of the build environment:

const globalConfig = {
    libraryName: 'Ray',
    outDir: resolve(dirname(fileURLToPath(import.meta.url)), '../dist'),
    basePath: resolve(dirname(fileURLToPath(import.meta.url)), '..'),
    builds: [
        {
            entry: 'src/Ray.ts',
            outfile: 'web.cjs',
            target: 'browser',
        },
        {
            entry: 'src/Ray.ts',
            outfile: 'web.js',
            target: 'browser',
        },
        {
            entry: 'src/RayNode.ts',
            outfile: 'index.cjs',
            target: 'node',
        },
        {
            entry: 'src/RayNode.ts',
            outfile: 'index.js',
            target: 'node',
        },
        {
            entry: 'src/Ray.ts',
            outfile: 'standalone.js',
            target: 'browser',
        },
        {
            entry: 'src/Ray.ts',
            outfile: 'standalone.min.js',
            target: 'browser',
        },
    ],
    /** @type Record<string, any>|null */
    pkg: null, // assigned in init()
    getDependencies(standalone = false) {
        if (standalone) return [];

        return Object.keys(this.pkg.dependencies).concat([
            'node:fs',
            'node:fs/promises',
            'node:os',
            'node:path',
            'node:process',
        ]);
    },
    async init() {
        this.pkg = JSON.parse(await readFile(resolve(this.basePath, 'package.json')));

        this.builds = this.builds.map(config => {
            config.entry = resolve(globalConfig.basePath, config.entry);
            config.minify = config.outfile.includes('.min.');
            config.standalone = config.outfile.includes('standalone');
            config.format = config.outfile.endsWith('.js') ? 'es' : 'cjs';
            if (config.standalone) {
                config.format = 'iife';
            }

            return config;
        });
    },
};

This object encompasses everything from the library name to output directories and build configurations. The libraryName sets the identity for the library being built. The outDir and basePath properties, derived from the current file (the build script, build.js), establish the path used for the output and project root directories.

The builds array is a collection of build configurations, each tailored to a specific target, such as the browser or NodeJS. The outfile extension, .js or .cjs, dictates whether the output format is ESM or CommonJS, respectively.

The pkg property, once initialized, holds the parsed contents of package.json, providing access to project dependencies. This is necessary so we can tell Vite to not include them in the final bundles, with the exception of the standalone build. The standard bundles will be installed via an NPM package, so their dependencies will automatically be installed, making them unnecessary to include in the bundles.

The getDependencies and init methods are where the global configuration object shines. getDependencies dynamically determines external dependencies, essential for configuring our bundling process, since we're also building a "standalone" bundle ("iife" format) in addition to the ESM and CJS builds.

The init method initializes the global configuration by reading and parsing package.json, then refining the build configurations for use later by Vite's build API.

Now on to the build function itself, which uses the Vite API to perform a build asynchronously:

async function buildWithVite(config) {
    await viteBuild(defineConfig({
        build: {
            lib: {
                entry: config.entry,
                name: globalConfig.libraryName,
                formats: [config.format],
                fileName: () => config.outfile,
            },
            emptyOutDir: false,
            outDir: globalConfig.outDir,
            minify: config.minify || false,
            sourcemap: true,
            rollupOptions: {
                external: globalConfig.getDependencies(config.standalone),
                // don't eliminate any "unused" code, since it's a library:
                treeshake: false,
            },
            target: config.target === 'browser' ? 'chrome70' : 'node18',
        },
        resolve: {
            extensions: ['.ts', '.js'],
            alias: {
                '@': `${globalConfig.basePath}/src`,
            },
        },
    }));
}

This function is a testament to the power and flexibility of Vite. It leverages viteBuild and defineConfig to orchestrate the build process, tailoring it to each configuration defined in our global setup. Through asynchronous execution, it processes each build configuration, taking into account settings such as entry points, output formats, and targets.

Lastly, we define and call a main() function that initializes the global configuration, then calls the buildWithVite() function above for each build configuration:

async function main() {
    await globalConfig.init();
    await Promise.all(globalConfig.builds.map(config => buildWithVite(config)));

    console.log('All builds completed');
}

main();

By leveraging the asynchronous functionality of NodeJS, our build script concurrently processes all six configurations, streamlining the build process:

There you have it — a comprehensive, ~100 line, asynchronous build script for multiple library outputs - all built in 1 second - thanks to the power of Vite. This approach not only simplifies the build process but also eliminates the need for multiple configuration files and CLI runs, offering an efficient solution for library development.

Essential Command Line Tools for Developers

Patrick Organ — Mon, 15 Jan 2024 13:18:52 +0000

As a software developer, having a selection of great command line tools at your disposal is essential. Once you've harnessed the power of the command line, you're more productive; you have the tools necessary to quickly complete common tasks.

The following is a list of command line tools I've cultivated over the years in my career as a Software Engineer; most of which I use on a daily basis, and all of which enable me to be highly efficient and productive.

This list only includes projects that provide native binaries - npm packages such as eslint or prettier, while incredibly useful, aren't included.

General Utilities

zyedidia/eget

zyedidia / eget

Easily install prebuilt binaries from GitHub.

Eget: easy pre-built binary installation

Eget is the best way to easily get pre-built binaries for your favorite tools. It downloads and extracts pre-built binaries from releases on GitHub. To use it, provide a repository and Eget will search through the assets from the latest release in an attempt to find a suitable prebuilt binary for your system. If one is found, the asset will be downloaded and Eget will extract the binary to the current directory. Eget should only be used for installing simple, static prebuilt binaries, where the extracted binary is all that is needed for installation. For more complex installation, you may use the --download-only option, and perform extraction manually.

For software maintainers, if you provide prebuilt binaries on GitHub, you can list eget as a one-line method for users to install your software.

Eget has a number of detection mechanisms and should work out-of-the-box with most…

Commit message	Tag increase
`chore: foo`	Nothing
`fix: fixed something`	Patch
`feat: added new button to do X`	Minor
`fix: fixed thing xyz` `BREAKING CHANGE: this will break users because of blah`	Major
`fix!: fixed something`	Major
`feat!: added blah`	Major

DEV Community: Patrick Organ

Developer Tooling #008

Developer Tooling #008

Zed

Visual Studio Code

Antigravity

Lapce

Pulsar

Cursor

Developer Tooling #007

Developer Tooling #006

Developer Tooling #005

Developer Tooling #004

Developer Tooling #003

Developer Tooling #002

Developer Tooling #001

From Contributor to Maintainer: Lessons from Open Source Software

Creating Open Source Projects

Contributing to Open Source Projects

Maintaining Open Source Projects

Mastering NPM Library Creation: Bundling with Vite

Building with Vite

Essential Command Line Tools for Developers

General Utilities

zyedidia/eget

zyedidia / eget

Easily install prebuilt binaries from GitHub.

Eget: easy pre-built binary installation

zyedidia/micro

zyedidia / micro

A modern and intuitive terminal-based text editor

Features

stedolan/jq

jqlang / jq

Command-line JSON processor

jq

Documentation

Installation

Prebuilt Binaries

Docker Image

Run with Docker

Example: Extracting the version from a package.json file

Example: Extracting the version from a package.json file with a mounted volume

Building from source

Dependencies

Instructions

ggreer/the_silver_searcher (ag)

ggreer / the_silver_searcher

A code-searching tool similar to ack, but faster.

The Silver Searcher

What's so great about Ag?

chmln/sd

chmln / sd

Intuitive find & replace CLI (sed alternative)

sd - search & displace

The Pitch

Comparison to sed

sharkdp/bat

sharkdp / bat

A cat(1) clone with wings.

Sponsors

Syntax highlighting

Git integration

Show non-printable characters

Automatic paging

charmbracelet/mods

charmbracelet / mods

AI on the command line

Mods

Installation

Development

go-task/task

go-task / task

A task runner / simpler Make alternative written in Go

Task

Gold Sponsors

cli/cli

cli / cli

GitHub’s official command line tool

GitHub CLI

Example: Extracting the version from a `package.json` file

Example: Extracting the version from a `package.json` file with a mounted volume

sd - `s`earch & `d`isplace

`next`, `n`

Install `golangci-lint`

⚡️Lightning-fast linter for `.env` files. Written in Rust 🦀