I have a recurring problem with Typescript where I can't search types for errors because all search engines are flooded with questions and articles about type checker errors.

lol

It's js, don't worry too much about the error types, hell, just use "throw 'string'"

If you need to provide more data on the error, just extend it yourself instead of using a builtin class that may or may not differ from the literal error class beside the name.

@melezorus34 I was looking to consume the errors produced by fs.promises.watch because if lots of things are modified quickly it tends to try to call the native watch function on a file that's been removed and I wanted to specifically catch and ignore this error.

fs.promises.watch should never throw enoent with any path other than its argument, I don't understand why Node doesn't filter out this case.

either way it's sorted now. I can afford dirty solutions here because this is just a tool script that watches some rust projects and copies the final executable into the vscode extension.

@lorentz dirty solutions is what js was made for. You are doing it right!

Just use any lmao
But seriously I hate typescript

@K-ASS And how is that gonna help me access a field? Getting the code to type check is neither difficult nor useful if it does the wrong thing 100% of the time because the name of a field is incorrect.

@lorentz IIRC fs.watch and derivatives (fs/promises) are somewhat platform dependent and hackily implemented. You may wanna use a third-party library.

@Ranchonyx Man, I fucking hate Node. Imagine building a runtime so that JS can run everywhere, turning it into the ultimate cross-platform language and your project into the bridge head everywhere that isn't the web, and then defining a platform-dependent API.

@Ranchonyx fs.promises.watch leaks file watchers. It's working for now but the next time I need to touch that script I'm yanking it right out.

@lorentz Yeah, it's massively fucked. I build my stuff for windows most of the time and when I go put it on any unix-like system, all goes well except for a tiny little thing which breaks the whole spiel.

Don't get me wrong, I like node, especially with typescript. You can build solid stuff with it and it puts food on my table, but holy fuck it can be a pain at times.

fLoOdEd

dude what the fuck are you talking about

@fullstackcircus Any query I try returns content about various type errors, reasons why Typescript wouldn't detect your declarations, and other content related to errors produced by Typescript, but nothing about the types _of_ errors raised by something else. Even if I emphasize the library, the results will be about Typescript not detecting the typings for that library.

@lorentz idk, I’m just hating typescript in general

@lorentz dude, that's xy problem

Just define a wrapper module that takes the fs module and export as is except for watch.

I can make you an example if you throw a coin to this witcher ($1 bid on github sponsors, one time)

You SHOULD be able to name this package fs, with or without warnings, and still have the native module be accessible via "node:fs" name

@lorentz also for not recognizing definitions, did you make a tsconfig.json file, or are you rawdogging it? Rawdogging causes ONLY the open files to be parsed and recognized.

@melezorus34 I was looking for a type for the error returned by fs because I needed to filter it. Since TS doesn't support typing error propagation explicitly I'd have had to cast to the error type anyway, but I was hoping to get autocomplete and inline docs for the type.

In the end I applied the info found in the node docs directly, without type support.

Not that it matters, I switched to the callback-based fs.watch in the end which hides all errors and doesn't leak watches anyway.

@lorentz yup, especially with promises. Weird stuff.