Hi !!! While some real human intelligence can step in, here is what ængel says about your original issue , and about the way to retrieve the ACI of an existing contract…
Hope it helps!
Problem Summary
Even though the aeproject.config.js contains the correct compiler and node URLs (pointing to Docker container IP 172.22.0.3), the test suite still tries to connect to 127.0.0.1:3080, which results in a ECONNREFUSED error.
That means: aeproject is ignoring your config.
Likely Root Cause
aeproject’s internal tooling (especially the testing framework) might not be correctly resolving aeproject.config.js due to ES module syntax or execution context.
Suggested Fixes & Workaround
1. Check ES Module Compatibility
If you’re using export default in aeproject.config.js, make sure the rest of your project supports ES modules (type: "module" in package.json).
Alternatively, change your config to use CommonJS:
js
Copy
// aeproject.config.js
module.exports = {
compilerUrl: 'http://172.22.0.3:3080',
nodeUrl: 'http://172.22.0.3:3013',
networkId: 'ae_dev',
};
And update your import in test/exampleTest.js:
js
Copy
const config = require('../aeproject.config.js');
2. Use Explicit SDK Initialization
Instead of relying on the utility method utils.getSdk(), manually configure the SDK to ensure it’s using the right endpoints:
js
Copy
import { AeSdk } from '@aeternity/aepp-sdk';
before(async () => {
aeSdk = new AeSdk({
nodes: [{ name: 'devnet', instance: new Node(config.nodeUrl) }],
compilerUrl: config.compilerUrl,
});
});
3. Verify Docker Network Bridge
Confirm that your test container can actually see 172.22.0.3. Try a curl or ping from within the container:
bash
Copy
curl http://172.22.0.3:3080/version
If it fails, your Docker network is misconfigured. You might want to:
- Connect both containers to a user-defined bridge network
- Or use Docker Compose with shared service names.
Test It Out
After making those changes, run:
bash
Copy
aeproject test
or if you’re just using Mocha directly:
bash
Copy
npx mocha ./test/**/*.js
Recommended Setup (For Fresh Start)
- Use WSL2 with Docker
- Use aeproject and localnet for local dev
- Stick to CommonJS for compatibility
- If you’re using VS Code, run the test terminal inside WSL context
Would you like a full Docker Compose + aeproject setup I can send you as a boilerplate to start fresh with best practices?
Always check important information and audit mainnet code. AI can be wrong. This assistant is a community effort and is not affiliated with the æternity foundation. Its sole aim is to support the æcosystem’s growth.
The above is about the original issue, below the answer to the ACI question .
How to Get ACI of an Already Deployed Contract
Yes, you can retrieve the ACI (Abstract Contract Interface) from a deployed contract — assuming you still have access to the original .aes source and/or its compilation artifacts.
Here’s how you can do it properly with the æpp SDK JS (v14):
Option 1: Compile Source to Get ACI (Preferred)
If you still have the .aes file, use the @aeternity/aepp-calldata package:
js
Copy
import { generateAci } from '@aeternity/aepp-calldata';
const fs = require('fs');
const contractSource = fs.readFileSync('./contracts/MyContract.aes', 'utf-8');
const aci = await generateAci(contractSource);
console.log(JSON.stringify(aci, null, 2));
Option 2: From Contract Instance via SDK (Post-Deployment)
If you already have the deployed contract address, and your SDK is initialized, do:
js
Copy
const contract = await aeSdk.getContractInstance({
source: './contracts/MyContract.aes',
contractAddress: 'ct_2abc123...',
});
console.log(contract.aci);
Note: You still need the contract source file to load the ACI this way. The ACI itself isn’t stored on-chain. If you don’t have the source anymore, and no published artifact (like in aepp-contracts repo), you’d need to reconstruct it manually or from someone who deployed it.
SDK Reference & Learning Resources
Here’s a cheat list to get comfy with @aeternity/aepp-sdk-js v14:
SDK Docs (Official)
SDK GitHub (v14+)
- SDK Repo
- Look inside
/packages/aepp-sdk for core logic
- Docs in
README.md and examples in /examples
Sample Init With Local Config (Best Practice)
Here’s a fresh pattern to get aeSdk running with your custom local net params:
js
Copy
import { AeSdk, Node } from '@aeternity/aepp-sdk';
const aeSdk = new AeSdk({
compilerUrl: 'http://172.22.0.3:3080',
nodes: [{ name: 'local', instance: new Node('http://172.22.0.3:3013') }],
address: 'ak_...', // optional default account
});
Bonus: Deploy a Contract and Fetch ACI
const contract = await aeSdk.getContractInstance({
source: fs.readFileSync('./contracts/MyContract.aes', 'utf-8'),
});
await contract.deploy();
console.log('Deployed at:', contract.address);
console.log('ACI:', JSON.stringify(contract.aci, null, 2));
TL;DR
- Yes, you can get ACI — but you still need the source or build artifact.
- Use
aepp-calldata or getContractInstance(...) with a path to source.
- Always match SDK version to example — v14+ has some breaking changes.
- For local dev, set
compilerUrl and nodes explicitly in your code — don’t rely on config imports alone.
- Check out examples in aepp-sdk-js — they’re gold for learning.
If you want, I can prepare a custom starter kit repo for you that’s fully wired up with WSL/Docker + aeproject + VSCode dev container support.
Would that help?
Always check important information and audit mainnet code. AI can be wrong. This assistant is a community effort and is not affiliated with the æternity foundation. Its sole aim is to support the æcosystem’s growth.