yoti Named export 'IDVClient' not found v4.5.1 Issue

[ramshid]

We encountered an issue with version 4.5.1 of the library where the named export 'IDVClient' is not found.

import {
IDVClient,
} from 'yoti';

const idvClient = new IDVClient(
            YOTI_CLIENT_SDK_ID,
            YOTI_PEM
        );

Our server automatically updates to the latest version of the 'yoti' library upon deployment. As a result, we encountered this issue after deploying version 4.5.1. Downgrading to version 4.5.0 temporarily resolved the issue.

PS: we are not using any TypeScript.

[laurent-yoti]

Hi @ramshid !

Apologies for the delay.
Could you please tell use a bit more about your project setup.

As per the root cause of your issue, I am not so sure... the version 4.5.1 is only introducing the TS support and generates a side /types folder, which should not influence your existing setup, which does not rely on TS.
In the latest version, we have not introduced code change per se, and the IDVClient is still exported as before.

We tested the changes via the examples in the project, yet, granted this is a bit old school as these use require, see the code in examples/idv/src/controllers/use-cases.
Then, we also tested in some internal Typescript project, without noticing any problem.

Therefore, we would need to know a bit more about your project setup, how come you are using import but no Typescript, you are using ESM? or transpile your files?

Then, could you please check if using the following pattern would solve it:

import yoti from 'yoti';
const { IDVClient } = yoti;

[BorisBarzotto]

import yoti from 'yoti';
const { IDVClient } = yoti;

Hi trying to use import yoti from yoti in nextjs 15 route handler an get:

  3 |
  4 | import { NextResponse } from 'next/server';
5 | import yoti from 'yoti';
  6 |
  7 | export async function GET() {
  8 | {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'scandir',
  path: 'C:\\Users\\Usuario\\Desarrollo\\Gerardo\\lacnic-auth\\[project]\\node_modules\\yoti\\src\\proto\\root.js [app-route] (ecmascript)\\definitions',
  page: '/api/create-session'
}

I have tried several ways to solve, so far I had to create a server in express to work with Yoti and the rest of the app in NextJs, but it can't import it, it needs require(“yoti”) and when using import which is what is used in Nextjs it fails. I have tried in server actions, route handlers and server components, it simply fails to import. I think as I see it is related to a .proto file and some incompatibility with turbopack. If anyone has an idea of how to make it work let me know. Thanks

[BorisBarzotto]

Hi again, I managed to get it working in nextjs 15 after trying all day.
I leave here the solution in case someone else has the same problem:

First in the next.config.ts configuration we add:

import type { NextConfig } from “next”;

const nextConfig: NextConfig = {
    serverExternalPackages: ['yoti'],
};

export default nextConfig;

This above will allow us to use require to import yoti
Then where we import it we mute the eslint and typescritp notification.

/* eslint-disable @typescript-eslint/no-require-imports */
const yoti = require('yoti');
/* eslint-enable @typescript-eslint/no-require-imports */

There we have yoti up and running without any problems.

[bee-drouen]

Hi, I have found a similar issue as I'm going through the Yoti onboarding.

I am deploying my Yoti client to AWS Lambda, using TypeScript & esbuild to build & tree shake for lambdas.

The first issue is with the default lambda esbuild deployment, where I see:

  message: "ENOENT: no such file or directory, scandir '/var/task/definitions'",
  stack: "Error: ENOENT: no such file or directory, scandir '/var/task/definitions'\n" +
    '    at Object.readdirSync (node:fs:1584:26)\n' +
    '    at getFilesPathsRecursively (/node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/root.js:6:13)\n' +
    '    at node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/root.js (/node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/root.js:20:26)\n' +
    '    at __require2 (file:///var/task/index.mjs:17:51)\n' +
    '    at node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/types.js (/node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/types.js:1:14)\n' +
    '    at __require2 (file:///var/task/index.mjs:17:51)\n' +
    '    at node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/index.js (/node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/proto/index.js:1:15)\n' +
    '    at __require2 (file:///var/task/index.mjs:17:51)\n' +
    '    at node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/yoti_common/index.js (/node_modules/.pnpm/yoti@4.11.1/node_modules/yoti/src/yoti_common/index.js:6:22)\n' +
    '    at __require2 (file:///var/task/index.mjs:17:51)',

Which seems to be from bundling CJS code to ESM, where yoti itself is trying to use a require statement for protobufjs.

Therefore, I had to mark yoti as being in nodeModules (a list of modules that should be installed instead of bundled).

Once I've made that change, I see the same error as flagged in the original issue here. The solution then being that I need to import yoti via a require (as mentioned above), but to ensure this is compliant with our lint rules & has all the necessary type definitions, I have had to create this workaround wrapper:

/* eslint-disable eslint-comments/no-unlimited-disable -- There's a lot of lint errors */
/* eslint-disable -- This breaks all our patterns, but it's yoti's fault */

// Import all types
import type { 
  IDVClient as IDVClientType,
  NotificationConfigBuilder as NotificationConfigBuilderType,
  RequestedDocumentAuthenticityCheckBuilder as RequestedDocumentAuthenticityCheckBuilderType,
  RequestedFaceMatchCheckBuilder as RequestedFaceMatchCheckBuilderType,
  RequestedLivenessCheckBuilder as RequestedLivenessCheckBuilderType,
  RequestedTextExtractionTaskBuilder as RequestedTextExtractionTaskBuilderType,
  SdkConfigBuilder as SdkConfigBuilderType,
  SessionSpecificationBuilder as SessionSpecificationBuilderType,
} from 'yoti'

import type CreateSessionResultType from 'yoti/types/src/idv_service/session/create/create.session.result'

// Require the actual implementation
const yoti = require('yoti')

// Export the actual implementations with proper typing
export const IDVClient: typeof IDVClientType = yoti.IDVClient
export const NotificationConfigBuilder: typeof NotificationConfigBuilderType = yoti.NotificationConfigBuilder
export const RequestedDocumentAuthenticityCheckBuilder: typeof RequestedDocumentAuthenticityCheckBuilderType = yoti.RequestedDocumentAuthenticityCheckBuilder
export const RequestedFaceMatchCheckBuilder: typeof RequestedFaceMatchCheckBuilderType = yoti.RequestedFaceMatchCheckBuilder
export const RequestedLivenessCheckBuilder: typeof RequestedLivenessCheckBuilderType = yoti.RequestedLivenessCheckBuilder
export const RequestedTextExtractionTaskBuilder: typeof RequestedTextExtractionTaskBuilderType = yoti.RequestedTextExtractionTaskBuilder
export const SdkConfigBuilder: typeof SdkConfigBuilderType = yoti.SdkConfigBuilder
export const SessionSpecificationBuilder: typeof SessionSpecificationBuilderType = yoti.SessionSpecificationBuilder

// Also export the instance types for convenience
export type IDVClient = IDVClientType
export type NotificationConfigBuilder = NotificationConfigBuilderType
export type RequestedDocumentAuthenticityCheckBuilder = RequestedDocumentAuthenticityCheckBuilderType
export type RequestedFaceMatchCheckBuilder = RequestedFaceMatchCheckBuilderType
export type RequestedLivenessCheckBuilder = RequestedLivenessCheckBuilderType
export type RequestedTextExtractionTaskBuilder = RequestedTextExtractionTaskBuilderType
export type SdkConfigBuilder = SdkConfigBuilderType
export type SessionSpecificationBuilder = SessionSpecificationBuilderType
export type CreateSessionResult = CreateSessionResultType

export default yoti

This solution cannot be permanent. Yoti not supporting proper ESM compilation means:

• It can't be bundled/tree shaken, significantly increasing lambda size
• This increases cold start times in serverless environments
• It forces developers to create hacky workarounds that break standard patterns
• It's incompatible with modern JavaScript tooling that defaults to ESM

Could the Yoti team please prioritize adding proper ESM support? This would solve the bundling issues and allow the package to work seamlessly with modern JavaScript build tools without requiring these workarounds.