DEV Community: Richard Zampieri

Web/Mobile Personal AI CFO

Richard Zampieri — Sat, 21 Feb 2026 10:00:50 +0000

How I Built an AI-Powered Finance App and distributed it's services to support volume and concurrency

A technical high level walkthrough of building a personal finance application that combines traditional CRUD with AI features—and why I split the services

The Problem

I wanted to build a personal finance app that could do more than track transactions. I wanted it to understand your finances: answer questions in natural language, categorize expenses automatically, and even take voice input, like a real personal assistant, so users dont have to type everything, you can ask Finny. The challenge? Most AI work happens in Python, while typical web backends live in Node.js. How do you get the best of both worlds without a tangled mess?

This is how I did it.
Obs: remember that are more than one way to skin the cat and all comes down to concurrency, volume, cost, context in which your app will start running.

High-Level Architecture

I chose a dual-backend architecture: one service for the core application, another dedicated entirely to AI. Here's the flow:

Frontend: React with TypeScript and Vite. Pages, components, contexts, and hooks all feed into a single API abstraction layer.

ExpressoTS API: Handles all non-AI operations—transactions, accounts, goals, budgets, auth. We use ExpressoTS—a type-safe TypeScript framework I created about five years ago for building scalable Node.js APIs. Database used Postgres.

Python AI Service: A separate service for everything AI: RAG (retrieval-augmented generation) for chat, transaction classification, voice transcript parsing, and document extraction. It calls out to an LLM provider for embeddings and completions. Good tip here is OpenRouter!

Why Split the Backend?

1. Keep API Keys Server-Side

AI providers require API keys. We never expose them in the frontend. All AI requests flow through our Python service, which holds the credentials and proxies requests. The browser never talks to the AI provider directly.

2. Python's Strengths for AI

Transaction classification, embeddings, RAG pipelines—these are natural fits for Python. The ecosystem (NumPy, pandas, OpenAI SDK, etc.) is mature. Trying to replicate that in Node would mean more custom code and more maintenance.

3. Independent Scaling and Concurrency

CRUD traffic and AI traffic have different profiles. With two services, we can scale each independently. A spike in chat usage doesn't affect the core transaction APIs. The ExpressoTS API handles many concurrent requests efficiently—it's built for speed with minimal overhead—while the Python service processes AI workloads in isolated batches. That separation means we're not blocking CRUD requests while classification jobs run, and vice versa.

4. Clear Separation of Concerns

Developers know exactly where logic lives: business data and CRUD in ExpressoTS, AI and ML in Python. That separation makes onboarding and refactoring much easier.

Frontend Structure

The app follows a clean layering pattern:

Layer	Location	Responsibility
UI	`components/`, `pages/`	Presentational components only
State	`contexts/`, `hooks/`	Global state and reusable logic
Data	`api/`	All data-fetching and API calls
Utils	`utils/`	Pure functions, no side effects

The api/ folder is the single entry point for backend communication. It doesn't care whether a request goes to ExpressoTS or Python—it just exposes functions like fetchTransactions(), classifyTransactions(), or askFinny(). The rest of the app stays unaware of the dual-backend setup.

The Python AI Service: What It Does

RAG for Financial Q&A

Users ask questions like "How much did I spend on groceries last month?" or "What's left in my dining budget?" The RAG service:

Generates an embedding for the user's question
Searches a vector store for relevant transactions, goals, and spending caps
Injects that context into the LLM prompt
Returns an answer grounded in the user's actual data

We store embeddings for transactions, categories, goals, and budgets. Vector search returns the most relevant slices of data, and the model answers from that—no hallucinations about numbers.

Batch Transaction Classification

When users upload a CSV from their bank, we have dozens or hundreds of uncategorized transactions. The classifier:

Uses the user's existing category hierarchy
Learns from past classifications (e.g., "Starbucks" → Coffee)
Returns structured JSON with category and subcategory IDs

We batch transactions to stay within token limits and process them asynchronously for speed. The frontend shows progress and then refreshes the list when done.

Voice Input

Users can speak a transaction: "Fifty dollars at the gas station for fuel." The voice parser turns that into structured fields:

Amount: 50
Description: Gas station
Category: Transportation
Subcategory: Fuel

The transcript is sent to the Python service, which returns a transaction object ready for the user to confirm or edit before saving.

Patterns That Worked

1. Context-Aware AI

The RAG service receives user_id and household_id from the auth token. Every query is scoped to that user's data. There's no risk of leaking one household's finances into another's answers.

2. Rate Limiting and Usage Tiers

AI calls are expensive. We enforce per-user limits: X chat queries, Y voice sessions, Z classifications per month. Free users get a taste; paid users get more. Limits are checked in middleware before any AI logic runs.

3. Caching Where It Makes Sense

Stateless questions like "What's my total income this year?" can be cached. We cache by query + user_id with a short TTL. Conversational threads aren't cached—they're too dynamic.

4. Tool Calling for Actions

The chat isn't just Q&A. Users can say "Add twenty dollars for lunch" and the AI triggers a tool that creates a transaction. We define tool schemas (add_transaction, get_balance, etc.) and the LLM decides when to call them. The Python service executes the call and returns the result for the model to summarize.

What I'd Do Differently

Start with the dual-backend split from day one. I flirted with a monolith and then split. Migrating mid-build was painful.
Standardize error handling early. ExpressoTS and Python return errors in different shapes. I added a shared error format layer later—would've saved time to do it upfront.
Invest in embedding pipelines sooner. RAG quality depends on good embeddings. We iterated on what to embed (full transaction text vs. summaries) and when to re-index. Doing that earlier would have improved the chat experience faster. There's more to it, obviously can't reveal all strategies used, but this is a good start. :)

Takeaways

Building an AI-powered app doesn't mean throwing everything into one stack, specially if you're vibe coding (be cautious). Splitting the backend—ExpressoTS for CRUD, Python for AI—gave me:

Clear ownership of API keys and AI logic
The right tool for each job
Independent scaling, concurrency, and deployment
A maintainable codebase

If you're considering adding AI to an existing app, or starting fresh with AI in mind, a dedicated Python, rust or c++ service for all AI workloads is a pattern that scales well.

Performance and Cost: Why This Matters When You're Starting Out

When you're building your first product or bootstrapping a side project, every dollar counts. Hosting an app and running AI can get expensive fast. This architecture helps on both fronts.

Concurrency without over-provisioning. The dual-backend split means CRUD and AI run on different processes. The ExpressoTS API can handle thousands of lightweight requests (transactions, account fetches, auth checks) on a modest instance, while the Python service runs AI jobs asynchronously. We're not paying for one beefy server that sits idle waiting for AI calls—we right-size each service. A small Node instance for the API and a small Python instance for AI often cost less than a single large monolith trying to do both.

Lower infrastructure cost. By isolating AI workloads, we avoid scaling the entire app when chat usage spikes. A free-tier or low-cost Python host can handle the AI service early on. As usage grows, we scale only that service. The CRUD API stays stable and cheap.

Cost-effective from day one. I built this understanding that building and hosting has to be cost-effective, especially for developers starting their own business. You don't need Kubernetes or a fleet of containers to launch. Two small services, clear boundaries, and the ability to scale each independently—that's a path that keeps bills low while you validate your product.

I'm the developer behind FinTrack, a personal finance app with an AI called Finny as your best advisor. If you're building something similar, I'd love to hear how you approached it—drop a comment below.

NPM Shield

Richard Zampieri — Mon, 17 Mar 2025 21:23:50 +0000

🚀 Introducing NPM Shield – Secure Dependencies 🛡️

Two months ago, we launched Better NPM. Since then, we've received numerous feature requests, UI improvement suggestions, and valuable feedback—including constructive criticism. We listened carefully, tested the waters, and understood developers' needs regarding dependency management, security, detailed package insights, and robust analytics.

Today, we're excited to announce the next evolution—now rebranded as NPM Shield!

Why NPM Shield? Because it reflects our commitment to protecting your projects through transparency, robust analytics, and comprehensive security.

Here's what's new and improved:

✅ Advanced Security Scans – Instantly identify vulnerabilities and risks across your entire dependency tree (CVE and CVSS).
✅ Detailed Package Insights – Gain deeper visibility into maintenance, adoption, and community health of your dependencies.
✅ Dependency Tree Graphs – Visualize your project's dependencies clearly and intuitively.
✅ Risk Mitigation Tools – Proactively address and fix dependency risks before they affect your project.

🔗 Check it out here: NPM Shield

A huge thank you to the community for your invaluable feedback. Your insights have shaped NPM Shield, helping us build a smarter, safer, and more transparent package ecosystem.

💬 We're eager to hear your thoughts on NPM Shield—your feedback drives continuous improvement!

Let's build secure, reliable software together. 💪

Our LinkedIn

Better NPM

Richard Zampieri — Wed, 19 Feb 2025 08:27:14 +0000

🚀 Reimagining NPM: A Smarter, More Secure Package Ecosystem

🌐 Better NPM

Package managers—from npm to vcpkg, Conan, Cargo, nuget-dotnet, pip, Maven, and beyond—often fail to give you a complete view of a package before you add it to your project. In today’s rapidly expanding (and often insecure) internet, developers need better tools and insights to ensure that each dependency they bring in is secure, well-maintained, and widely adopted.

Many organizations take security seriously, yet still rely on patchwork solutions that small companies often can’t afford. That’s why we built a lightweight layer on top of NPM—we’re calling it Better NPM – ExpressoTS Store—to deliver a comprehensive view of every package you consider. This includes data on security breaches, maintenance status, and adoption rates. We’re also focusing on providing ecosystem-wide details that help you scan your project, spot potential vulnerabilities, and make truly informed decisions when selecting dependencies. (SCAN in development)

Why Better NPM – ExpressoTS Store?

✅ Transparency: Gain rich insights into package security, maintenance activity, and adoption statistics.
✅ ExpressoTS Plugin Hub: Discover all plugins built for the ExpressoTS Framework in one place.
✅ Better Analytics for Maintainers: Understand how packages are used and receive feedback on how to improve them (feature in development).
✅ A Unified Marketplace: A central hub for vetted plugins and extensions, ensuring consistency and quality.

🔐 Security at the Core: Stop scavenging GitHub issues and third-party tools. Our goal is to arm you with detailed security info up front, so you can focus on building rather than endlessly verifying.

Want to know more?

📩 Reach out our Tech Evangelist: https://www.linkedin.com/in/umataldetatiana/

🚀 Check out our very beta store: https://lnkd.in/gGKMHzN6
Let’s build a better, smarter package ecosystem together! 💡

3.0 is Here!

Richard Zampieri — Thu, 05 Dec 2024 18:21:47 +0000

ExpressoTS v3.0 is Here! 🎉

This major update brings significant enhancements to ExpressoTS Framework.

Reduced Dependencies: Streamlined for lighter and faster applications.
Custom IoC Container
Embedded Environment Management: Now built into the framework for simplicity.
New @expressots/shared Package: Consolidates utilities for modular development.
Micro API Template: Quickly prototype microservices for enhanced scalability.
Streamlined Application Structure: Centralized configuration in app.ts for easier maintenance.
Rendering Engine Support: Use EJS, Handlebars, Pug, and more via plugins.
Plugin System: Extend functionality effortlessly with custom plugins.
CLI Improvements: Enhanced commands, performance boosts, supporting npm, yarn, and pnpm.
Improved Testing: Migrated to Jest with extensive unit tests and high coverage. Thanks to Early AI
Improved security score, thanks to Snyk Health Package Extension

For more information checkout the full article here!

"How the Open Source Project Uses EarlyAI to Enhance Framework Code Quality"!

Richard Zampieri — Mon, 04 Nov 2024 16:52:12 +0000

Join us on November 12 for an exclusive webinar:

In this webinar, Richard Zampieri ( @rsaz ) and Sharon Barr will share how EarlyAI is used by @ExpressoTS to generate high coverage, quality unit tests in a click.

ExpressoTS’s approach focuses on more than just code coverage; it’s about gaining rapid insights to improve code quality directly through unit tests generated by EarlyAI. This tool acts as both a time-saver and a proactive bug detector, helping developers quickly identify areas for enhancement.

Don’t miss out on this chance to see how EarlyAI can transform the future of software development!

📅 Date: Tuesday, November 12
⏰ Time: 11am PST | 2pm EST | 9pm IL
🔗 Register: https://lnkd.in/dTsnNrBu

Unit Test Generation with Early AI

Richard Zampieri — Sun, 20 Oct 2024 08:47:41 +0000

Accelerating Unit Test Generation and Improving Code Quality

Recently, I had the opportunity to deep-dive into Early, an AI agent designed for automatic unit test generation. As someone who regularly works with TypeScript and ExpressoTS Framework, I was keen to see how Early could streamline my workflow. I decided to test the vscode extension they built on my new NPM library I was developing called @expressots/shared.

Initial Impressions

The first thing that struck me about Early was its ability to automatically generate unit tests for my existing codebase. Instead of crafting tests from scratch, I could focus on refining the generated tests and improving my code's robustness and testability. This shift significantly accelerated my development process. The other interesting aspect I noticed is that 83% of the code generated I didn't do any adjustment, it worked out of the box and increased my code coverage. Save me a huge time.

Time Savings and Increased Coverage

In just 8.5 hours, I managed to:

Generate unit tests for approximately 3,000 lines of code.
Fix issues and enhance code testability.
Achieve a total code coverage of 88% with 96 tests.

The fact that I could accomplish all this in a single day was remarkable. The ideal scenario in unit test is do it while you're actually developing your functions. I did after the fact that I had already a library in place, so some adjustments were necessary to make the code testable.

Positive Outcomes

Automatic Generation of Edge Case Tests. For instance, it generated unit tests for scenarios involving empty strings, even when parameters were required:

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

Initially, I wouldn't have created tests for empty strings in such a straightforward function. However, Early's approach promoted defensive programming practices, pushing me to handle edge cases I might have overlooked.

Detection of Potential Issues

While refining the generated tests, I encountered a type mismatch issue:

Problem: jest.fn() returns any, but process.exit returns never, leading to a type mismatch in TypeScript.
Solution: Modify the mock to match the process.exit signature, ensuring type correctness.
This discovery prompted me to adjust my code for better type safety, highlighting how Early can help identify subtle issues that might otherwise go unnoticed.

Areas for Improvement

Despite the overall positive experience, I encountered a few challenges that, if addressed, could enhance Early's usability:

Library Version Compatibility. Early generated tests using deprecated Jest methods in some cases, for example:

Using Jest 29.7

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

// Corrected version

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

Customization Options for Test Generation While generating tests for edge cases was beneficial, in some scenarios, it might not be necessary:

Observation: Generating tests for every possible input, including empty strings, can sometimes be overkill.

Suggestion: Introduce options to customize the level of test generation, allowing developers to opt-in for defensive programming tests as needed.

User Interface Enhancements in the VSCODE Extension Navigating between Early and other tools highlighted some UI limitations:

Test Results Visibility: I had to switch between Early and Jest to see which tests passed or failed.

File Tree State: The project hierarchy in Early collapses when switching back from other applications, requiring me to reopen folders repeatedly.
Suggestion: Improve the UI to display test results within Early, mirroring Jest's structure. Maintaining the state of the file tree would also enhance user experience.

Mocking and Type Safety The issue with jest.fn() returning any suggests a need for more precise mocking:

Observation: Using any types in mocks can lead to type mismatches and potentially mask bugs.
Suggestion: Refine mock generation to use accurate signatures, promoting better type safety and reducing the need for manual corrections.

Conclusion

Overall, my experience with Early was highly positive. The tool significantly accelerated my unit testing process, allowing me to focus on refining tests rather than writing them from scratch. It also encouraged me to consider edge cases and improve my code's robustness.

The areas for improvement are relatively minor and revolve around enhancing usability and customization. Addressing these would make the tool even more powerful ally in software development.

Kudos to the Early team for their excellent work! I'm excited to see how the tool evolves and would be happy to continue providing feedback to help refine it further.

Extras (CodeCov + Early)

A great way to enhance your code quality and coverage measurement is by integrating Codecov. Combining Early AI with Codecov creates a powerful first line of defense for ensuring high-quality code from the start.

Here is the repo in case someone want's to check it out: @expressots/shared

Badges:

CodeCov:

Drilling more on CodeCov:

You'll have clear insights into which parts of your code were covered and which weren't, making it easier to identify areas for improvement.

ExpressoTS surpassed AdonisJs

Richard Zampieri — Mon, 09 Sep 2024 20:04:13 +0000

🚀 Exciting Milestone Alert! 🚀

ExpressoTS has surpassed AdonisJS in weekly downloads after just 1.5 years! 🎉 We're quickly becoming the go-to framework for #NodeJS & #TypeScript devs.

Full details here

Exploring Rust in a Professional Setting: A C++ Engineer’s Perspective

Richard Zampieri — Wed, 07 Aug 2024 19:17:50 +0000

With over 23 years of experience as a C++ engineer, I’ve seen a lot of programming languages and technologies evolve. I’ve always been eager to explore new tools, and recently, I decided to dive into Rust. My current role as a Principal Engineer at a tech company gave me the perfect opportunity to try Rust in a real-world, professional setting.

The Project: System B Communication Layer

We recently started developing a robotics system, and I was tasked with building the architecture for communication between the system A and the system B. This involved creating a layer that interfaces with the System B using ROS2 and delivers messages to a desktop application.

For this layer’s API, I decided to give Rust a try. I bought a book, went through the entire tutorial, and got up to speed fairly quickly. For the UI, I chose Tauri as the framework for the desktop application, using Vue for the front-end.

First Impressions: A New Development Pattern

Rust’s programming paradigm is quite different from what I was used to with C++. If you come into Rust with an OOP mindset, you’re likely to struggle at first. Rust encourages a different way of thinking about memory management, ownership, and concurrency.

One of the biggest challenges I faced was dealing with the compiler. Rust’s compiler is notoriously strict, and you’ll spend a lot of time wrestling with it until you understand how it works. However, this is also one of Rust’s strengths. The compiler forces you to write safe, reliable code, which leads to fewer runtime errors.

The Crate Ecosystem: A Mixed Bag

Rust has a vast ecosystem of crates (libraries), which can be both a blessing and a curse. On one hand, there are millions of crates available for almost anything you can think of. On the other hand, many of these crates are low quality, and it can be challenging to find the ones that are truly useful.

If you’re serious about using Rust in a professional setting, you’ll need to be selective about the crates you rely on. The good news is that once you find the right tools, Rust’s ecosystem can be incredibly powerful.

The Turning Point: Embracing Rust’s Philosophy

After a while, I started to get the hang of Rust’s philosophy. I stopped fighting with the compiler and began to enjoy the coding process. One thing that really stood out to me was how reliable my code became. In C++, I’m used to dealing with warnings and errors during compilation, but with Rust, my code compiled cleanly and just worked.

The sense of security that comes from knowing your code is stable and reliable is one of Rust’s biggest advantages. It’s not something you often experience with C++.

Rust in Production: A Balanced View

In my experience, Rust is absolutely production-ready. It’s a joy to work with, and the language’s emphasis on safety and reliability is a huge plus. However, the ecosystem still has some catching up to do. I found myself building a lot of tooling and writing my own libraries to fill in the gaps for my specific project.

If you’re considering Rust for a professional project, be prepared to invest some time in building out your own tools and libraries. The language itself is fantastic, but you may need to do some extra work to get everything you need.

Final Thoughts: A Positive Outlook

Rust has a lot to offer, especially for developers who value safety, performance, and reliability. While the ecosystem is still maturing, the language itself is rock solid and ready for prime time. If you’re up for the challenge, Rust can be a rewarding addition to your toolkit.

In conclusion, Rust is a joy to program in, even if it requires some adjustment and a bit of extra effort. As the ecosystem continues to grow, I’m confident that Rust will become an increasingly popular choice for professional development. It’s already proven itself in my experience, and I’m excited to see where it goes from here.

ExpressoTS on The Rise???

Richard Zampieri — Sun, 28 Jul 2024 03:22:23 +0000

Hi Dev Community,

Over the past 3 to 4 weeks, we've observed a noticeable increase in downloads of the ExpressoTS framework. Let’s hope this upward trend continues! 🥂

Thank you for your contributions, engagement, and feedback. Your efforts have been instrumental in enhancing the platform and creating a better developer experience.

Best,

ExpressoTS Render Engine

Richard Zampieri — Tue, 23 Jul 2024 08:19:46 +0000

Render Engine

ExpressoTS enhances the web server capabilities of Express.js by providing a streamlined experience for rendering views. ExpressoTS supports various render engines out-of-the-box, including EJS, PUG, and Handlebars (HBS). This makes it easy for developers to start rendering views without needing additional configuration, as default settings are provided for each supported engine.

Supported Render Engines

ExpressoTS supports the following render engines:

EJS
PUG
HBS (Handlebars)

Handlebars Configuration Options

export type HandlebarsOptions = {
    viewEngine?: string; // The view engine to be used
    viewsDir?: string; // The path to the views folder
    partialsDir?: string; // The path to the partials folder
};

Default Handlebars configuration options

{
    viewEngine: "hbs",
    viewsDir: <root>/views,
    partialsDir: <root>/views/partials,
}

Default Folder structure

Default folder structure for Handlebars:

src
views
|--partials
|   |--partial.hbs
|--index.hbs

All other engines follow the same structure, with the exception of the partials folder, which is specific to Handlebars.

Handlebars File Example

<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>HBS Example</title>
    </head>
    <body>
        <h1>Hello from HBS</h1>
        <p>Render partial: {{> partial}}</p>
    </body>
</html>

Other Engine Configuration Options

Pug Configuration Options

export type PugOptions = {
    viewEngine?: string;
    viewsDir?: string;
};

Default Pug configuration options

{
    viewEngine: "pug",
    viewsDir: <root>/views,
}

EJS Configuration Options

export type EjsOptions = {
    viewsDir?: string;
    viewEngine?: string;
    serverOptions?: EjsOptionsServer;
};

Default EJS configuration options

{
    viewEngine: "ejs",
    viewsDir: <root>/views,
    serverOptions: {
        cache: true,
        compileDebug: false,
        debug: false,
        delimiter: "%",
        strict: false,
    },
}

How to use

Here's how you can set up ExpressoTS to use a render engine like HBS (handlebars) in your application:

In the app.provider configuration provider, you can set the render engine:

export class App extends AppExpress {
    private middleware: IMiddleware;
    private provider: ProviderManager;

    constructor() {
        super();
        this.middleware = container.get<IMiddleware>(Middleware);
        this.provider = container.get(ProviderManager);
    }

    protected configureServices(): void {
        // Set the render engine to HBS
        this.setEngine(Engine.HBS);

        this.middleware.setErrorHandler();
    }

    protected async postServerInitialization(): Promise<void> {
        if (this.isDevelopment()) {
            this.provider.get(Env).checkAll();
        }
    }

    protected serverShutdown(): void {}
}

If you want to pass custom options to the render engine, you can do so by passing an object with the desired options to the setEngine method. For example, to set the views directory to a custom path, you can do the following:

this.setEngine<HBS>(Engine.HBS, { viewsDir: <<custom-path>> });

How To Render Views in ExpressoTS

To render a view in ExpressoTS, you can use the render method provided by the Response object. Here's an example of how you can render a view in ExpressoTS:

@Get("/")
root(@response() res: Response) {
    res.render("index", { date: new Date(), name: "Random information" });
}

In the example above, the render method is called on the Response object, passing the name of the view to be rendered and an object with data to be passed to the view. The view engine will render the view with the provided data and return the rendered HTML to the client.

Render Decorator

The @Render decorator can be used on controller methods to render views using the specified view engine. Here's an example of how you can use the @Render decorator to render a view in ExpressoTS:

Rendering passing the view and default data in the decorator

@Get("/")
@Render("index", { date: new Date(), name: "Random information" })
root() {}

Rendering passing only the view in the decorator

@Get("/")
@Render("index")
root() {
    return { date: new Date(), name: "Random information" };
}

Happy Coding! 🐎

ExpressoTS - DB in Memory

Richard Zampieri — Sat, 06 Jul 2024 05:16:36 +0000

Explore our In-Memory DB in action! 🐎

This straightforward class enables developers to prototype APIs effortlessly, eliminating the need to connect to or set up database. Perfect for rapid development and testing!

Enhancing Rust Development: Introducing cargo-run for Script Management

Richard Zampieri — Thu, 27 Jun 2024 21:18:01 +0000

In the world of modern software development, package managers have become indispensable tools for developers. Languages like JavaScript/TypeScript (with npm/yarn), C++ (with CMake), and Java (with Maven/Gradle) all have sophisticated package managers that include powerful scripting capabilities. These script sections allow users to define custom build, prebuild, and test scripts, enhancing their development workflow.

However, when it comes to Rust, the Cargo package manager doesn't offer a built-in scripting feature in the Cargo.toml file. This often leads developers to rely on lengthy and complex command lines for various tasks. Recognizing this gap, I created a new crate called cargo-run that brings flexible, powerful scripting capabilities to the Rust ecosystem.

Introducing cargo-run

cargo-run is a Rust crate designed to run scripts defined in a Scripts.toml file. It aims to simplify and enhance script management in Rust projects, providing features that rival those found in other language ecosystems.

All current features

Run scripts defined in Scripts.toml.
Specify interpreters for scripts (e.g., bash, zsh, PowerShell).
Initialize a Scripts.toml file with default content.
Chain multiple scripts together using the include feature.
Set global environment variables and script-specific environment variables with precedence handling.

Why cargo-run?

cargo-run enhances the user script management and build process in ways that the standard build.rs file cannot. While build.rs is great for build-specific tasks, cargo-run allows you to define a wide range of scripts, from build and prebuild to testing, deployment, and more.

User-Friendly and Clean UI

One of the standout features of cargo-run is its readable and clean UI. When running scripts, cargo-run provides clear output, showing which script is currently running and the status of each script. This makes it easy for users to follow along with the script execution process and identify any issues quickly.

Here are a few scenarios where cargo-run shines:

Complex Build Pipelines: Define complex build pipelines that involve multiple steps and tools, all orchestrated through cargo-run scripts.
Cross-Platform Development: Use different interpreters to ensure your scripts run smoothly on different operating systems.
Environment Management: Manage environment variables effortlessly, ensuring your scripts have the right configuration for different environments (e.g., development, testing, production).

Example: Getting Started with cargo-run

Step 1: Initialize Scripts.toml

First, initialize your Scripts.toml file with default content:

cgs run init

Step 2: Define a Script

Next, define a simple build script in Scripts.toml:

[scripts]
build = "echo 'build'"

Step 3: Run the Script

Run the script using cargo-run:

cgs run build

Step 4: Chain Scripts Together

You can chain multiple scripts together using the include feature:

[scripts]
release = { include = ["i_am_shell", "build"] }

For more examples read the official documentation.

Conclusion

The cargo-run crate offers a powerful, flexible way to manage scripts in Rust projects. By bringing the script management capabilities of other language ecosystems to Rust, cargo-run simplifies complex workflows, enhances cross-platform development, and provides robust environment management.

Whether you're working on a simple project or a complex application, cargo-run can help streamline your development process. I encourage you to explore cargo-run and see how it can enhance your Rust development experience.

To get started, check out the cargo-run crate on crates.io and visit the GitHub repository for more details and documentation. Happy scripting!