Split deployer local & testnet/mainnet

[kwiss]

Describe the bug

To make developer experience better we should split the contracts.json in two separate files: local.contracts.json -> add that to gitignore contracts.json -> stay as it is but only for goerli/sepolia/mainnet

This change also implies to modify the build/dev for the core sdk that currently generate its build using contracts.json possible solution: use the env variables:

• STARKNET_NETWORK_ID=dev
• SOLIS_NETWORK_ID=dev To get the different & use the corresponding contracts.json

To Reproduce

• deploy local contracts
• check where deployed contracts are located (./contracts.json)

Expected behavior

• deploy local contracts
• create/override ./local.contracts.json

[muheebyusufbaba1]

I would like to work on this @kwiss

[Pycomet]

Can i work on this @kwiss

[danielcdz]

Hello @kwiss! My name is Daniel I'm an active contributor in OD this is my profile, I would like to help you with this issue, I will solve this by following your instructions, it seems to be very straightforward

[Ternder001]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

My recent focus in Ethereum-Solidity and Starknet-Cairo has significantly deepened my understanding of web3 technologies, positioning me well to contribute to innovative projects in the blockchain space. As an alumnus of Web3Bridge, where I received training in Solidity and Cairo, I have developed a solid foundation in these technologies. I am eager to contribute to open-source projects within the Starknet ecosystem, and I am particularly excited about the opportunity to make meaningful contributions to this project. Given the chance, I am committed to delivering my best work and leveraging my skills to drive success.

How I plan on tackling this issue

To address the problem of splitting contracts.json into two separate files for better developer experience, I would follow these steps:

1. Splitting the contracts.json File a. Create local.contracts.json

   Copy the existing contracts.json to local.contracts.json. Modify .gitignore to include local.contracts.json to ensure it is not tracked by Git.

b. Modify contracts.json

Ensure contracts.json only contains contract information for Goerli, Sepolia, and Mainnet networks.

2. Update the Build/Dev Process a. Modify SDK Build Process

   Update the core SDK's build scripts to differentiate between the environments using environment variables.

b. Implement Environment Variables

Use STARKNET_NETWORK_ID and SOLIS_NETWORK_ID to determine the appropriate contracts.json file to use.

3. Implementing the Changes a. Updating Deployment Scripts

   Adjust deployment scripts to write local contract information to local.contracts.json if the environment is local.

b. Adjusting Build Scripts

Modify build scripts to read the appropriate contracts.json file based on the environment variables.

4. Testing the Solution a. Local Testing

   Deploy contracts locally and ensure that local.contracts.json is created/updated correctly.

b. Network Testing

Deploy contracts on Goerli, Sepolia, and Mainnet to verify that contracts.json remains correct and unaffected by local deployments.

[Utkarsh-626744]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I am a software engineer at Zscaler with a year of experience in providing cloud security solutions. My role involves developing secure, scalable cloud-based applications, which has honed my skills in cloud infrastructure, security protocols, and system architecture. Additionally, I have developed a blockchain project that connects multiple wallets, showcasing my proficiency in blockchain technology, smart contract development, and Dapp deployment. This project is deployed on Netlify and available on my GitHub profile. My expertise in cloud security ensures that blockchain projects are secure from various threats while being scalable and efficient. I excel in integrating blockchain networks, deploying applications, and maintaining them using CI/CD pipelines. My collaborative approach, problem-solving skills, and customer-centric mindset further enhance my ability to deliver innovative and secure solutions in both cloud security and blockchain domains.

How I plan on tackling this issue

To approach the problem of separating local and network-specific contract deployments into different JSON files, I would follow a systematic process that ensures both backward compatibility and ease of use for developers. Here’s a step-by-step breakdown:

1. Understand the Current Setup Analyze the existing contracts.json structure: Determine how contracts are currently being recorded (e.g., contract address, ABI, network ID). Examine the build/dev pipeline: Understand how the SDK is currently using contracts.json during the deployment and build processes.
2. Design the New File Structure Create local.contracts.json: This file will store contracts deployed to the local environment. Add local.contracts.json to .gitignore to prevent it from being committed. Retain contracts.json: Keep this file for Goerli, Sepolia, and Mainnet deployments to avoid breaking existing functionality.
3. Modify the Deployment Scripts Update Deployment Logic: Identify the environment: Use environment variables (e.g., STARKNET_NETWORK_ID and SOLIS_NETWORK_ID) to determine whether the deployment is local or network-specific. Conditional File Writing: If the deployment is local, write the contract addresses and ABIs to local.contracts.json. If the deployment is on Goerli, Sepolia, or Mainnet, continue writing to contracts.json. Example Snippet (in JavaScript/TypeScript): javascript Copy code const fs = require('fs'); const networkId = process.env.STARKNET_NETWORK_ID || process.env.SOLIS_NETWORK_ID;

const isLocal = networkId === 'dev';

const filePath = isLocal ? './local.contracts.json' : './contracts.json';

// Assuming deployedContracts is the object with the deployment details fs.writeFileSync(filePath, JSON.stringify(deployedContracts, null, 2));

4. Adjust the SDK Build Process Adaptation to New Files: Modify the SDK build process to read from the appropriate file based on the environment. For instance: In a local environment, the SDK should load contract addresses from local.contracts.json. For other environments, it should load from contracts.json. Refactor Environment Configurations: Introduce logic in the SDK to determine which file to use based on the STARKNET_NETWORK_ID and SOLIS_NETWORK_ID.
5. Test the Implementation Unit Tests: Write unit tests for the deployment scripts to ensure contracts are being correctly written to the respective JSON files. Integration Tests: Perform end-to-end testing by deploying contracts in both local and network environments, verifying that the correct files are being created and used.
6. Documentation and Developer Guidance Update Documentation: Provide clear instructions in the README or other documentation on how the new file structure works. Include details on the environment variables and how they affect deployment. Developer Communication: Notify the team or developers who use the SDK about the changes, providing guidance on any required updates to their workflows.
7. Monitor and Iterate Feedback Loop: After deploying the changes, gather feedback from the developers to ensure the new process is intuitive and effective. Iterate if Necessary: If any issues or edge cases arise, quickly iterate to refine the approach, ensuring a smooth developer experience.