Setting Up a Cross-Platform Development Environment (EVM, Solana, etc.)

Modern Web3 development often requires interacting with multiple blockchains. A multi-chain development environment is a unified setup that allows you to build, test, and deploy applications across different ecosystems like Ethereum, Polygon, Arbitrum (EVM-based), and Solana. The core challenge is managing distinct toolchains, programming languages, and local networks. This guide outlines the essential components and a step-by-step approach to configure a robust, cross-platform workspace.

Your foundational setup starts with core developer tools. Install Node.js (v18 or later) and a package manager like npm or yarn. For EVM development, Hardhat or Foundry are the standard frameworks. Install Hardhat globally (npm install -g hardhat) to scaffold projects and run a local Ethereum node. For Solana, you need the Solana CLI Tool Suite and the anchor framework for Solana Program development. Use a version manager like nvm or asdf to handle multiple Node.js versions if needed for different toolchains.

Managing blockchain-specific dependencies is crucial. For EVM projects, your package.json will include libraries like ethers.js or web3.js, @openzeppelin/contracts, and testing suites. Solana projects require @solana/web3.js, @project-serum/anchor, and the mocha test framework. Use separate project directories or a monorepo structure (with Turborepo or Nx) to keep these dependencies isolated and avoid version conflicts. Configure separate hardhat.config.js and Anchor.toml files to define networks, accounts, and program IDs for each chain.

A local testing environment is non-negotiable. Hardhat includes a built-in network (npx hardhat node) for deploying and testing EVM smart contracts. For Solana, start a local validator with solana-test-validator and deploy your programs using anchor deploy. You can write integration tests that interact with contracts on both networks. Consider using Docker to containerize these local nodes, ensuring a consistent, reproducible environment that can be version-controlled and shared across your team.

Finally, streamline your workflow with scripts and IDE configuration. Create npm scripts in your package.json to run common commands for both environments, like test:evm and test:solana. Use VS Code with extensions: Solidity by Juan Blanco for EVM development and vscode-anchor for Solana. Proper environment variable management with dotenv is essential for storing RPC URLs and private keys securely. This setup enables you to efficiently context-switch and build truly interoperable applications.

Before writing your first line of code, you must establish a core toolkit. The essential components are a package manager, a runtime environment, and a version control system. For most developers, this means installing Node.js (v18+ or v20+ LTS) via nvm for easy version management, the npm or yarn package manager, and Git. This setup is non-negotiable for interacting with blockchain development frameworks like Hardhat, Foundry, or Anchor, which rely on Node.js for their scripting and plugin ecosystems. A solid IDE like VS Code, with extensions for Solidity and Rust, will significantly boost your productivity.

With the base layer installed, the next step is configuring the specific toolchains for your target chains. For EVM development, you have two primary choices. Hardhat is a TypeScript-based framework offering a rich plugin system for testing, deployment, and debugging. Foundry, written in Rust, provides a fast, direct toolchain (forge, cast, anvil) that is gaining popularity for its speed and built-in fuzzing tests. For Solana development, the Anchor Framework is the standard, requiring the Rust toolchain (rustc, cargo) and the Solana CLI (solana, spl-token). You will also need a local validator client like solana-test-validator for testing.

Managing multiple private keys and network configurations securely is critical. Never hardcode private keys or mnemonics. Use environment variables with a .env file (and a .gitignore entry) or a dedicated secrets manager. For EVM chains, tools like dotenv are common. For managing test funds, familiarize yourself with faucets for the relevant testnets (e.g., Sepolia, Holesky for Ethereum; devnet for Solana). You'll also need a blockchain explorer API key (from Etherscan, Solscan, etc.) for contract verification, a step often integrated into deployment scripts.

Finally, consider the system-level requirements. A multi-chain setup can be resource-intensive. Running local nodes (e.g., Hardhat Network, anvil, solana-test-validator) requires sufficient RAM (8GB minimum, 16GB recommended). Solid-state drives (SSDs) are highly recommended for faster compilation and node synchronization. Ensure your operating system is up to date, especially for managing dependencies and native bindings required by cryptographic libraries. Consistent environment setup across your team can be enforced using Docker containers or detailed provisioning scripts in your project repository.

Building for multiple blockchains like Ethereum (EVM) and Solana introduces a complex dependency matrix. You'll need different compiler versions (solc for Solidity, anchor for Solana), language-specific package managers (npm, Cargo), and native toolchains (Rust, Node.js). Conflicts arise when different projects require incompatible versions of these tools, leading to the infamous "it works on my machine" problem. The core challenge is achieving deterministic builds—ensuring that anyone, on any system, can compile your project with the exact same dependencies you used.

The first line of defense is a well-organized project structure. For a multi-chain project, consider a monorepo with clear separation. A common pattern is to have top-level directories like /evm/ for Hardhat or Foundry projects and /solana/ for Anchor workspaces. Each sub-project should have its own dependency manifest (package.json, Cargo.toml) and a lockfile (package-lock.json, Cargo.lock). Lockfiles are non-negotiable; they pin every transitive dependency to a specific version, preventing silent updates that can break builds. Never commit a project without them.

For system-level tooling, version managers are essential. Use nvm (Node Version Manager) to install and switch between specific Node.js versions, and rustup to manage Rust toolchains and targets. You can specify the exact version in a .nvmrc or rust-toolchain.toml file at your project root. For Solidity, Foundry's forge manages solc versions automatically via its foundry.toml. For Hardhat, you must specify the compiler version in hardhat.config.js. This approach isolates project requirements from your global system state.

When version managers aren't enough, use containerization or system-level package management. Docker is the most robust solution, allowing you to define the entire OS, libraries, and tools in a Dockerfile. This guarantees absolute environment parity. For a lighter-weight, more Unix-native approach, Nix and Nix Flakes offer reproducible development environments. A shell.nix or flake.nix file declaratively specifies every dependency, from openssl to solc 0.8.19, creating an isolated shell with precisely those tools available.

Here's a practical example using a flake.nix for a project needing Node.js 18, Foundry, and the Solana CLI:

nixCopy
{
  description = "EVM + Solana dev environment";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default = let pkgs = nixpkgs.legacyPackages.x86_64-linux; in pkgs.mkShell {
      buildInputs = with pkgs; [
        nodejs-18_x
        foundry
        solana-cli
        rustup
      ];
    };
  };
}

Running nix develop drops you into a shell with these exact versions, regardless of your host OS.

Finally, automate setup and verification. Include a Makefile or scripts (scripts/setup.sh) that run your environment checks (e.g., solc --version, anchor --version). Integrate this into your CI/CD pipeline (GitHub Actions, GitLab CI) using the same Docker image or Nix derivation defined for development. This creates a single source of truth for dependencies from local development through to production builds, effectively eliminating version conflicts and making your project truly portable across teams and platforms.

An isolated project workspace prevents dependency conflicts and ensures your development environment is consistent across machines and team members. For blockchain development, this is critical when working with multiple chains like Ethereum, Arbitrum, or Solana, each requiring specific toolchains and versions. The core tools for achieving this are Docker for containerization and Nix for declarative package management. Docker packages your entire app and its OS dependencies, while Nix guarantees that every developer installs the exact same versions of compilers and libraries, eliminating "it works on my machine" issues.

For EVM development, start by containerizing your environment. A Dockerfile should specify a Node.js or Python base image, then install critical tools like foundry (Forge/Anvil), hardhat, or brownie. Pin all versions explicitly. For example, RUN curl -L https://foundry.paradigm.xyz | bash && foundryup --version nightly-8a7c0d5a. This ensures your team uses the same Solidity compiler and testing framework. Use Docker Compose to orchestrate local nodes like Anvil or Hardhat Network alongside your application for integrated testing.

Solana development requires a different toolchain. Your isolated setup must include the solana-cli, anchor framework (version 0.29.0 or later), and rust with the correct target (solana). A Nix shell (shell.nix) is highly effective here, as it can provide the exact Rust toolchain and Solana programs SDK. You can define packages like rustc, cargo, solana-cli, and nodejs-18_x in a declarative configuration that any developer with Nix can instantiate identically.

Version control is integral to this workflow. Your repository should include the Dockerfile, docker-compose.yml, and/or shell.nix files. Never commit node_modules or other locally built artifacts. Instead, include a Makefile or package.json scripts with commands like make setup that run docker build or nix-shell. Document the prerequisites (Docker Desktop, Nix package manager) clearly in a README.md. This makes onboarding new contributors a one-command process.

The final step is integrating this isolated environment into your CI/CD pipeline. Services like GitHub Actions or GitLab CI can use your Dockerfile to build an image and run your test suite in a clean environment on every commit. For Nix, you can use cachix to cache binary builds, dramatically speeding up pipeline execution. This guarantees that what you test in isolation is exactly what gets deployed, closing the loop on environment reproducibility from local development to production.

Your environment is now configured to build and test applications across major blockchain platforms. You have Hardhat for EVM chains like Ethereum, Arbitrum, and Polygon, and Anchor for Solana. Tools like solana-test-validator and a local Hardhat node allow for rapid iteration without gas fees. The next step is to solidify this knowledge by building a simple, cross-chain application, such as a token bridge front-end or a multi-chain NFT viewer.

To deepen your expertise, explore platform-specific advanced topics. For EVM development, learn about EIP-4337 Account Abstraction using libraries like @account-abstraction/sdk or dive into Layer 2 tooling with frameworks like foundry. For Solana, experiment with Cross-Program Invocations (CPIs) and Program Derived Addresses (PDAs). Understanding these concepts is critical for building complex, interoperable dApps.

Finally, integrate monitoring and deployment. Use services like Tenderly or Alchemy to debug EVM transactions and Solana Explorer for Solana. For deployment, familiarize yourself with CI/CD pipelines using GitHub Actions to automate testing and publishing to networks like Sepolia or Solana Devnet. Consistent practice and building real projects are the most effective ways to master cross-chain development.