Checking Lib Types Using TSC

[Offroaders123]

I've run into multiple issues with using new-javascript over time where the types appear to be not working nicely together just from using them with "types": ["new-javascript"].

Is this project edited in conjunction with tsc checking all of the file references? The only way to fix these errors is to enable "skipLibCheck": true, but that has shown to make things less accurate for me, because it also disables checking of my own .d.ts files for my app, not solely the ones in ./node_modules.

I tend to run a terminal window alongside my editor while I write in one file, as you can catch reference/type issues in other files when you change the exports from the file you have open. I think that appears to be some of the main issues with new-javascript's errors. I think part of the issue may also be that the project doesn't have a tsconfig.json, which would help narrow the use of types, in that you can enable things like "strict": true, which will ensure that un-typed any values don't go undeclared. There appears to be a few of those, where return types aren't defined, so my tsc is picking up on them being undeclared as any, since my project has "strict": true set.

[BenjaminAster]

Thanks! Ok, there are two things here:

1. There was indeed some nonsense in my code (mostly <reference>s to deleted or renamed files and one untyped return value, as you already figured out), which I fixed now.
2. The reason for most (28) of the errors is, however, still the collision between the types from lib.dom.d.ts and lib.webworker.d.ts, as new-javascript references both of them. For checking the new-javascript types themselves, I think we will have to use tsc index.d.ts --strict && tsc worker.d.ts --strict as I don't see a simple way to tell tsc in a tsconfig.json that it should treat the DOM-related types from new-javascript separately from the worker-related ones (also, when tsc-ing .d.ts files directly, the tsconfig.json is completely ignored). For the errors that appear in projects using new-javascript, you have to (as explained in new-javascript's readme) exclude the files in tsconfig.json, e.g. in your Dovetail project you can add "./public" to the "exclude" property in the tsconfig & remove the var self = ... line in service-worker.js and it should work (with lib check enabled).

[Offroaders123]

I ended up moving my Service Worker over to a full TypeScript file as well, and this issue still occurs, and I was hoping to look into figuring out a fix for it again. Any new tips or ideas on this one?

[BenjaminAster]

If I clone Dovetail and add

"exclude": [
  "./src/service-worker.ts",
],

to the tsconfig.json, it works just fine for me, even after removing the

declare var self: ServiceWorkerGlobalScope;

in service-worker.ts. What am I missing here?

[Offroaders123]

Looks like it does work! Ideally I wouldn't have to exclude it from the tsconfig.json though, since that removes it from my type checking config, so it doesn't follow the same rules the rest of the project does (tsc or tsc --watch). Is the only way to manage it to exclude it, and maybe use a second tsconfig.json instead?

[Offroaders123]

Ok, here's another possible one, is there a way to make a library that is loaded as a <reference lib/> type? Rather than a <reference types/> one? That should in theory prevent the overlap with the standard library I think? Or would that mean that loading those types would spill over into my other modules code' types as well? Because that seems to happen for other kinds of projects of mine when using only a single tsconfig.json as well.

Here's the current state of things for reference:

[BenjaminAster]

The problem is that TypeScript fundamentally has terrible support for mixing different execution contexts (i.e. main thread/workers/worklets etc.) in a single project. As soon as there is a tsconfig.json file present in a directory, all /// <reference />s as well as the types of the compilerOptions.types array apply to all TS files. Suppose you have the following files:

tsconfig.json:

{}

main.ts:

document;
FileReaderSync;
export {};

worker.ts:

/// <reference no-default-lib="true" />
/// <reference lib="WebWorker" />
/// <reference lib="WebWorker.Iterable" />
document;
FileReaderSync;
export {};

you would expect FileReaderSync to error in main.ts, and document to error in worker.ts. Instead, document errors in both files, simply because the <reference />s from worker.ts also apply to main.ts. If you now e.g. add

/// <reference lib="DOM" />
/// <reference lib="DOM.Iterable" />

to main.ts, or if you include any types referencing the DOM lib (e.g. new-javascript or better-typescript) in compilerOptions.types, both the DOM types and the WebWorker types get included in all TS files, which is also not what you want.

Personally, I hate configuration files of all kinds with a passion, and as I'm perfectly happy with the global js/ts.implicitProjectConfig. options in VSCode's settings.json, I usually simply don't use tsconfig.json files at all, making all those problems go away. If you do want to use tsconfig.jsons, I still haven't found another way than to "exclude" your worker files.

---

I think TypeScript simply treats <reference lib="LIBRARY_NAME" /> as a kind of "redirect" to <reference path="path/to/internal/node_modules/typescript/lib/lib.LIBRARY_NAME.d.ts" />, so I don't think loading types via <reference lib=... /> instead of <reference types=... /> would make a difference (also I'm pretty sure it's impossible).

[BenjaminAster]

@Offroaders123 Ok, I've now completely rearchitected new-javascript and better-typescript in a way that I've always considered to do but never did because it's very ugly and hacky: I copied all the webworker-exclusive types from lib.webworker.d.ts into a TS file to expose those types globally while completely removing all lib="WebWorker" references. As far as TypeScript is concerned, all your TypeScript files (both main thread and workers) are now always "on the main thread", and self always has a type of Window & typeof globalThis, but both the DOM-exclusive and the webworker-exclusive stuff are available everywhere, so you the developer have to figure out what you may use where. better-typescript then extends these types with service- and shared worker types. So now you can simply add

{
  "compilerOptions": {
    "types": ["better-typescript"], // or "new-javascript" if, for whatever reason, you don't want the better-typescript stuff
  }
}

to the tsconfig or add

/// <reference types="better-typescript" />

to a TS file and all files will get all DOM and all worker types.

Note that this is a breaking change, since referencing new-javascript/worker.d.ts doesn't work anymore (this file has been repurposed for TS definitions for all webworker stuff). Let me know what you think!

[Offroaders123]

It's not working when loaded through npm, I think the package.json isn't associating the types completely.

{
  "compilerOptions": {
    "types": [
      "better-javascript",
      "vite/client"
    ]
  }
}

[BenjaminAster]

@Offroaders123 The packages are called better-typescript and new-javascript; better-javascript doesn't exist :)

[Offroaders123]

Oops, that makes perfect sense
Can't believe I missed that 😂