Hi @constantin-cool-needle,
The GeneratedScriptCodeAccessor class has always lived under an internal module path, but the project template introduced stricter linting rules in ext4 that now correctly flag imports from internal/ paths. Your dev tools setup can be adapted without relying on that import at all.
Assumed A12: 2025.06-ext4 (from thread context)
1. Workaround: drop the instanceof check and use the key instead
Instead of checking value instanceof GeneratedScriptCodeAccessor in your replacer, you can identify the code accessor by its key. The replacer function receives the property name as key — for code accessor values that key is "generatedCodeAccessor". So you can replace the instanceof check with a simple string comparison on key.
For typing value["script"] you can use the IGeneratedCodeAccessor interface, which is the return type of createScriptAccessor and is part of the public API. That way you keep full type safety without importing any internal class.
Your replacer would look roughly like this:
function replacer(key: string, value: any): any {
if (key === "generatedCodeAccessor") {
return {
script: (value as IGeneratedCodeAccessor)["script"],
__serializedType__: "GeneratedScriptCodeAccessor",
};
}
return value;
}
The reviver stays the same since it already uses GeneratedCodeAccessorFactory().createScriptAccessor(...) which is public API.
2. Upcoming project template improvement
We created a ticket for the project template to ship a default EnhancerOptions configuration that includes a reviver/replacer pattern for code accessor hydration out of the box. Once that lands, new projects will have this wired up automatically and you won’t need to maintain the custom serialization setup yourself.
3. If you still need a public GeneratedScriptCodeAccessor
If your project has a specific need for GeneratedScriptCodeAccessor to be publicly available (beyond the dev tools use case), feel free to create an A12 request ticket for that. We can evaluate making it part of the public API.
Note: The // @ts-expect-error suppression works as a short-term fix, but switching to the key-based check described above is the cleaner path and avoids relying on internal module structure entirely.
Cheers, Markus
