Is it expected for typescript target files generated by compactc to be empty?

Technical Questions
, ,
1

I currently have two contracts: a.compact:

module a {
   export sealed ledger num: Uint<8>;
}

b.compact:

import "a";

constructor() {
  num = 10;
}

Is it expected for typescript target files generated by compactc to be empty and look like this:

import type * as __compactRuntime from '@midnight-ntwrk/compact-runtime';

export type Witnesses<T> = {
}

export type ImpureCircuits<T> = {
}

export type PureCircuits = {
}

export type Circuits<T> = {
}

export type Ledger = {
}

export type ContractReferenceLocations = any;

export declare const contractReferenceLocations : ContractReferenceLocations;

export declare class Contract<T, W extends Witnesses<T> = Witnesses<T>> {
  witnesses: W;
  circuits: Circuits<T>;
  impureCircuits: ImpureCircuits<T>;
  constructor(witnesses: W);
  initialState(context: __compactRuntime.ConstructorContext<T>): __compactRuntime.ConstructorResult<T>;
}

export declare function ledger(state: __compactRuntime.StateValue): Ledger;
export declare const pureCircuits: PureCircuits;
1 Like
2

Yes, that’s expected. That contract actually does have a ledger field num in its public state, but the field’s not been exported from the contract (b.compact) so it’s not visible from the DApp’s JS code. You need:

export { num };

in b.compact for that. If contract b doesn’t re-export members of module a then they’re “private” from the JS code.

It’s moderately confusing that export does something (slightly) different in a module definition (makes it available to Compact code that imports the module) and at the top level of a contract (makes it available to the JS code).

The compiler is sometimes aggressive about throwing away unneeded code, but in this case you can see that the constructor is there even when you don’t re-export the module’s field. Search for 10n in index.cjs to see it.

1 Like