linting and feedback

[alexanderchan]

Just wanted to say, I went through the implementations on theo's try-catch gist and have to say I like yours a lot. It's clean and simple and works even if it's early on. They should have a kudos page instead of just an issues page in github! Appreciate you releasing it.

Hope you keep it up, these are only suggestions because it's your library but perhaps something helpful while you are building things to get some early feedback. Maybe worth opening discussions tabs for this type of general feedback rather than real a real issue (which these aren't)

• Eslint vs Language extensions -- I totally see why you would want an extension but for adoption the lint rule might be easier to adopt. Language extensions are just a bit less common imho. https://typescript-eslint.io/ shows us how some features of ts can be leveraged so maybe that's helpful? It might be just in my head but I see this type of thing as linting because it's syntactically correct but it's preferred to manage the error. Lint rules like this are relatively easy to generate these days so maybe for developer experience choosing the one that fits the toolchain might be an option? Either way I really appreciate that you've included this as a part of the packages. This can be something you consider once the api is stabilized as well or take contributions.

• I personally like the go data, err syntax and since this form of error handling is really appealing to go devs it seems to make sense to keep it that way as well so I like that you chose that order

• Maybe just lean into the try-catch name? try-catch-tuple is just a little more of a mouthful and if it's namespace scoped to you already it's probably ok?

• object notation - I did like how czy-js had both object and tuples but the types did not work for me so maybe the complexity of the dual typing isn't worth it. It's easier to have a single api to document and support anyways.

Really looking forward to see where you take this!

[lugrinder]

I agree with @alexanderchan; ESLint rules are easier to adopt.
Transformers are nice for tsc, but not for other transpilers like Bun.
Implement an ESLint rule as well, and let the user decide its use.

[maxmorozoff]

Hey @alexanderchan,

Thanks a lot for your thoughtful feedback! I really appreciate it.

I've converted this to a discussion per your suggestion - it's definitely a better place for general feedback like this.

ESLint vs Language Extensions

Great point about typescript-eslint, and I appreciate the reference! I've been considering ESLint support, and the monorepo structure will help if we decide to integrate it. Ideally, we could reuse some logic between the TypeScript and ESLint plugins.

I originally prioritized a TypeScript plugin approach because ESLint was painfully slow in my projects, even with relatively small repos (~400 files, ~25k LOC). Biome is much faster, but not as mature as ESLint yet. The upcoming v2 with GritQL integration looks promising, though from what I understand, it won't have access to type information - only syntax analysis (let me know if I'm wrong on this).

Additionally, deno lint now supports custom plugins (though still experimental), so that could be an interesting option down the line. If we structure things well, we might be able to reuse logic across both TypeScript and ESLint plugins, and potentially Deno as well.

Currently, I'm refactoring the TypeScript plugin to optimize AST traversal and remove duplicated logic between code fixes and diagnostics. I ended up breaking some things in the process, so I decided to write proper unit and E2E tests first (right now, E2E tests in /examples are pretty minimal).

Additionally, I've found some edge cases with Promise.all, so I want to address those before adding more features.

That said, any help or contributions are always welcome!

Go-style Syntax

I personally prefer [data, error] over { data, error } or [error, data], and I want to take it even further. My plan is to introduce utilities that make handling returned errors (rather than thrown errors) similar to how Go handles errors.

Naming

I totally agree that the current package names are a bit long, especially since they're scoped under my username. I've already reserved the @try-catch npm org and plan to move the packages there. Some potential naming options:

• @try-catch/tuple - aligns well with the repo name
• @try-catch/utils - feels more generic and might make sense if the API grows

For plugins, @try-catch/ts-plugin and @try-catch/eslint-plugin seem straightforward. Open to any other suggestions!

Object Notation

One of my main concerns with an object notation approach is that it's easy to forget to handle the error. Go handles this naturally, and I wanted a way to enforce it with tooling in TS.

With tuples, we can enforce error handling while still allowing [data, ,] to ignore the error explicitly. With objects, there are only two real options:

// @ts-expect-error (or @ts-ignore)
const { data } = tryCatch(...)

or

const { data /* error */ } = tryCatch(...)

Neither feels intuitive, and comments aren't stored in the AST, which increases tooling complexity. So, for now, I'll be sticking with tuples - but I'm open to reconsidering if tooling evolves to support objects better.

---

Again, thanks for the feedback! Looking forward to hearing more thoughts.

[lugrinder]

I've detected an issue with your approach, the problem of patching.
I have a monorepo using pnpm, and all packages uses the same Typescript version. After applying the ts-patch, one of the packages based in Vue, raises an error when try to build this package: TypeError: Cannot read properties of undefined (reading 'useCaseSensitiveFileNames'). Probably because all packages are really using the same copy, due pnpm, of the Typescript.
So, this solution will also not valid when I'll try to implement the tryCatch in the Vue app.

[maxmorozoff]

Nice catch! Will look into this. Feel free to open an issue if you want to share more information or steps to reproduce - like your TypeScript, Vue, and ts-patch versions, or a minimal repro.

Should we add a pnpm monorepo to /examples for test coverage on this kind of setup? 🤔

[alexanderchan]

naming

nice! I like that you reserved it, that'll be really great. It's a small thing but little devx touches are much appreciated.

ESLint vs Language Extensions

That makes a lot of sense on performance. It's unfortunate that it looks like for the next little while we'll be non standardized with all of the different tooling options for these operations. With tsc, eslint and now others like biome and oxc it gets much harder for library devs -- but hopefully best for the community in the long run once one of these proves to be the new linting tool of choice. I will let you know if I take a stab at writing a lint rule but the language extension should work until then.

Go-style Syntax
I personally prefer [data, error] over { data, error } or [error, data], and I want to take it even further. My plan is to introduce utilities that make handling returned errors (rather than thrown errors) similar to how Go handles errors.

This sounds great, unkey has an interesting approach to returned errors and I like the idea of having typed errors coming back but they return { val } | { error }. Typed errors like neverthrow are nice as well. A wrapper to convert data returned errors into the actual type would be very cool.

if I'm understanding it, it'd be to manage errors like

function myExample() {
  if (Math.random() < 0.5) {
    return new Error("Too small"); // instead of throw new Error('Too small')
  }

  return { message: "ok" };
}

I think what makes your library work well is there's less api surface area to learn initially and then with utils or different interfaces we could support the more advanced use cases like returned errors. Looking forward to seeing this.

Object Notation

Coming from react, tuples feel natural enough as long as it's really tuples and it's close to how golang does it.. somehow when it gets beyond two and no longer a tuple but an array I find it harder to track 😄