error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled

[aspenflow]

In MacOS Monterey when attempting to build WebCord:

> webcord@4.4.0 build
> tsc
sources/code/main/modules/socket.ts:43:14 - error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled.
43       return WebSocketClose.TryAgainLater;
                ~~~~~~~~~~~~~~

sources/code/main/modules/socket.ts:91:29 - error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled.
91       return Promise.reject(WebSocketClose.TryAgainLater);
                               ~~~~~~~~~~~~~~

Found 2 errors in the same file, starting at: sources/code/main/modules/socket.ts:43

Error looks similar to this: vitejs/vite#5814

but forking and setting preserveConstEnums to false as suggested in the referenced issue results in the following output:

> webcord@4.4.0 build
> tsc

sources/code/main/modules/socket.ts:2:51 - error TS2307: Cannot find module '@hainesdata/disconnection' or its corresponding type declarations.
2 import { WebSocket, HookFn, WebSocketClose } from "@hainesdata/disconnection";
                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                    
sources/code/main/modules/socket.ts:38:29 - error TS7006: Parameter 'details' implicitly has an 'any' type.
38   void server.details?.then(details => server.log(l10n.client.log.listenPort.replace("%s",kolor.underline(kolor.blueBright("%s"))), details.port));
                               ~~~~~~~

sources/code/main/modules/socket.ts:39:79 - error TS7006: Parameter 'parsedData' implicitly has an 'any' type.
39   const hookDialog: HookFn<"GUILD_TEMPLATE_BROWSER"|"INVITE_BROWSER"> = async(parsedData, origin) => {
                                                                                 ~~~~~~~~~~

sources/code/main/modules/socket.ts:39:91 - error TS7006: Parameter 'origin' implicitly has an 'any' type.
39   const hookDialog: HookFn<"GUILD_TEMPLATE_BROWSER"|"INVITE_BROWSER"> = async(parsedData, origin) => {
                                                                                             ~~~~~~

sources/code/main/modules/socket.ts:81:40 - error TS7006: Parameter 'parsedData' implicitly has an 'any' type.
81   server.addHook("DEEP_LINK_CHANNEL", (parsedData) => {
                                          ~~~~~~~~~~
                                          
Found 5 errors in the same file, starting at: sources/code/main/modules/socket.ts:2

[SpacingBat3]

I'm pretty sure preserveConstEnums were actually supposed to make it work with isolatedModules once I've added this to tsconfig.json and without this, it just gets worse. This is as isolatedModules enforces in TypeScript a mechanism to make sure transpilers that operate on single file level and don't contain full type information are actually able to transpile the code without runtime errors – since those transpilers might not understand types or references to the external const enums (and basically leave the references to const enums as is, without replacing the const enum references with the respective values – as const enums are not available in runtime and needs to be further resolved), I've additionally made them available at runtime (deconstified, so it can be actually imported at runtime).

Also in case of WebCord, isolatedModules should not be set as true, at least it isn't for my repo and I'm pretty sure I haven't touched tsconfig.json that much. CI also seems to succeed, which confirms that's the upstream defaults. EDIT: Looks like TypeScript added that to their latest strictest TSConfig preset, WebCord now contains isolatedModules: false.

Seems that TypeScript Handbook actually mentions that I should also remove const from const enum in TypeScript's declarations at post-build step if I want TypeScript to think it's not an ambient enum, but I guess that means loosing all benefits of const enum by TypeScript API consumers that don't need isolatedModules: true in their tsconfig.json.

I guess I might go for different approach: define exports and add @spacingbat3/disconnection/no-const-enum API, which would basically be a reference to main.js with .d.ts files that contains no const enum references. But in reality the optimal sollution would be for TypeScript to know which const enum declarations are also available in runtime and which doesn't, so no patching like this has to be done just to ignore the error.

[SpacingBat3]

(...) but forking and setting preserveConstEnums to false as suggested in the referenced issue results in the following output (...)

I literally use the site search functionality (CTRL+F) to find where you read this would help. I see no mentions of that (I see only disabling isolatedModules as a sollution).

Also the errors are most likely as you've most likely setup the dependencies in wrong way. I suppose you want to replace it this way (at least if you want to test the version from GitHub repository – you might as well reference the path to use the local version on your disk so you won't need to publish the changes to GitHub each time you test something):

"dependencies": {
# (...) - whatever dependencies you got here
-	"@spacingbat3/disconnection": "^1.0.0"
+	"@spacingbat3/disconnection": "github:hainesdata/DisConnection"
}

Then, you don't have to replace the @spacingbat3/disconnection reference in source code with @hainesdata/disconnection. You only modify package.json and run npm i.

[SpacingBat3]

Also another workaround would be to just ignore these errors, with //@ts-expect-error directives, since the code seems to be emitted correctly (there's a reference to const enum in JS and since it's available at runtime – this is completely fine to be left as-it-is). So yeah, TypeScript could just not emit any errors at all for this code, I guess it just doesn't have any knowledge about const enums being available at runtime as well.