o1js is not quite compatible with NodeNext TSC module resolution

[ukstv]

If you use NodeNext module resolution setting,
an instance of ZkProgram can not be exported. TSC complains it can not actually infer types.

See reproduction case: https://github.com/ukstv/o1js-nodenext-repro

Probably related issue: microsoft/TypeScript#47663

[mitschabaude]

oh that's bad! looking into it

[mitschabaude]

started to debug this, some notes:

you can get rid of some of the warnings by importing every type from o1js (not claiming that this is a solution, just mentioning for further investigation)

import type * as o1js from "o1js";

however, what persists are warnings about field.js and bool.js, and I haven't figured out yet exactly how to make them disappear.

When looking at the generated d.ts files, you'll find stuff like import('field.js').FieldVar and import('field.js').Field all over the place.

So there might be two problems:

• The fact that we don't export FieldVar and FieldConst
• The weird type override we do in core.ts to get Field to be a function and class and type at the same time

[mitschabaude]

Btw, I don't get what exactly makes "nodenext" behave differently here. Types should be (and seem to be) imported from node_modules/o1js/dist/node/index.d.ts no matter the module resolution config

[mitschabaude]

Another long-shot idea is that the cycle of imports between bool.ts and field.ts could be a source of problems since

TypeScript imitates the host’s module resolution, but with types

[mitschabaude]

Ok, I made a lot of progress debugging, will leave this draft PR here for now: #1448

The key change in that PR is to export InternalField and InternalBool from field.ts and bool.ts directly. They can't seem to be resolved to their aliases Field and Bool in "nodenext" mode.

With that PR, the following snippet type-checks. Note the many "unused" type imports, each of which is necessary to "name" the inferred type of HelloProgram

import {
  Bool,
  Field,
  ZkProgram,
  Proof,
  InternalBool,
  InternalField,
  Cache,
  GateType,
  Gate,
  FieldVar,
  FieldConst,
} from "o1js";

export { HelloProgram };

const HelloProgram = ZkProgram({
  name: "hello-program",
  publicInput: Field,
  publicOutput: Bool,
  methods: {
    addition: {
      privateInputs: [Field, Field],
      method(sum: Field, a: Field, b: Field) {
        return a.add(b).equals(sum);
      },
    },
  },
});

alternatively, this could be used:

import { Bool, Field, ZkProgram } from "o1js";
import type * as _o1js from "o1js"; // for type naming

export { HelloProgram };

const HelloProgram = ZkProgram({
  name: "hello-program",
  publicInput: Field,
  publicOutput: Bool,
  methods: {
    addition: {
      privateInputs: [Field, Field],
      method(sum: Field, a: Field, b: Field) {
        return a.add(b).equals(sum);
      },
    },
  },
});

[ukstv]

That's not ideal, but it works :) When is the release?

[mitschabaude]

That's not ideal, but it works :) When is the release?

not sure if we want to release that yet

[dfstio]

See also the discussion on discord https://discord.com/channels/484437221055922177/1205086733121888266

I've encountered many issues with o1js and nodenext in my MinaNFT library, and after trying many ways to resolve it, I finally decided to wait for TypeScript bug resolution microsoft/TypeScript#47663 and microsoft/TypeScript#48212.

I believe that the bug is on TypeScript side, and only some temporary workarounds can be made in the o1js or minanft library.

[mitschabaude]

We should check if TypeScript 5.5 which includes microsoft/TypeScript#42873 resolves this

[ukstv]

@mitschabaude Nope. Does not work. Now even import type does not work.

Updated the repro repo with the newest TS.

[mitschabaude]

I just struggled with this on a new repo again and was forced to use the deprecated module resolution mode there, vote for re-opening