Currently, you won't get proper typing unless you manually add .default to you photon instance.
const Photon = require('@generated/photon');
const photon = new Photon.default();
What I will suggest is also to export a named model Photon. Otherwise, even though Babel will transform .default interop exports but we will lose typing information using default exports. Named exports solve this completely.
.default vscode will show a lack of call signature error
.default vscode will just assign any to the photon variable, this results in loss of autocompletion.

Potential fix, named export for Photon.
I suggest to use named exports instead and change the API to:
// JS
const { Photon } = require('@prisma/photon')
// TS / modern JS
import { Photon } from '@prisma/photon'
This will guarantee consistent usage/examples "in the wild" (e.g. StackOverflow, tutorials, GH issues, ...)
We had a longer internal discussion about this and want to go with
// JS
const { Photon } = require('@generated/photon')
// TS / modern JS
import Photon from '@generated/photon'
We will explore, if we can "enforce" the default export for TypeScript, if not, in TypeScript there will also be the named export of { Photon } available.
Multiple requirements that make the decision hard here:
We want to avoid as much as possible ambiguous usage of Photon.js. So having import { Photon } from '@generated/photon' and import Photon from '@generated/photon' could confuse users. However, as the name of "default" suggests - it's just a default for the simple use-case, so exporting it both as a default and a named export doesn't exclude each other.
Another option we were discussing but decided against: Setting
export = Photon
Which would need "esModuleInterop": true in the tsconfig.json and then allow
import Photon from '@generated/photon'
const Photon = require('@generated/photon')
However, this forces users to have a specific tsconfig.json, which may break their application if they're using import * as ... already.
As it turned out if we want to have the named export for the JavaScript implementation, we can't remove it for TypeScript. To keep things consistent, we've decided to go with
import { Photon } from '@generated/photon'
for both TypeScript and JavaScript.
Most helpful comment
As it turned out if we want to have the named export for the JavaScript implementation, we can't remove it for TypeScript. To keep things consistent, we've decided to go with
for both TypeScript and JavaScript.