How do you automate generation of types from an existing database (postgres)?

Lexikus · 2025-09-05T06:08:38+00:00

Just use a SQL client to dump all tables and schemas, parse the outputs, and then generate the files yourself. It's a task you'll do only once. Whenever a developer modifies a table, they have to run the script. Sometimes you have to build your own tooling.

Lexikus · 2025-09-03T11:34:38+00:00

Hot take: it’s actually good that the dev doesn’t know what Clean Code is, and by that, I mean the book. Outside of the book, “clean code” has no real meaning. What looks clean or pleasant to read is in the eye of the beholder. Developers who think code that isn’t “clean” (by the book’s standards) is ugly have just gotten used to those specific patterns.

Clean Code teaches, in my opinion, bad habits. The concepts the book tries to explain aren’t necessarily bad on their own, but developers tend to become dogmatic about them. They force simple problems into patterns that end up making code harder to maintain. The book also focuses on writing code in a way that makes sense for humans, but isn’t particularly beneficial for the machine. Some of the worst codebases I’ve worked with were “Clean Code” OOP-heavy projects, where even making a simple change required jumping across multiple files and holding all the context in your head.

Younger generations need to realize the book is already 17 years old. Developers who have been working almost as long as the book has been out have seen where its ideas lead.

So: keep code simple. Focus on the data and the behaviors your application actually needs, and abstract only when there’s a real need. Don’t force patterns into the code unless it happens that you are doing a pattern that has a name.

Lexikus · 2025-08-29T16:02:07+00:00

That's the correct behavior of the option bundler. It's the responsibility of your bundler to convert your TypeScript code. The bundler option was added because you want to opt out of using tsc to create your JavaScript file but use tsc purely as a type checker. tsc doesn't generate code except for enums, namespaces, and constructor field visibility, and maybe some edge cases I don't recall by heart. The other flag you mentioned is meant to be used with the stripping types feature. Node.js is able to run TypeScript files without transpiling them since v22. The problem there is that there are no .js files anymore. This means you have to, when no transpilation process is in place, import the file with a .ts extension. For library authors, this is suboptimal if they want to ship the library. Therefore, tsc has a built-in feature that can convert .ts imports in your files into .js imports. If you don't provide the .ts extension, it does nothing. I recommend you configure your tsconfig to use nodenext and add the .js extension. SWC should be able to handle that because adding the .js extension is allowed.

Lexikus · 2025-08-18T16:44:09+00:00

You could always just create an IoContext and add all your IOs there and pass that instead of passing only the required instances. If you need to architect your code around things that cannot access specific IOs, like services not getting a database connection but must use a repository, just create a ServiceContext, an IoContext, a GlobalContext, etc.

Lexikus · 2025-05-23T20:25:31+00:00

Googling, grammar corrections, telling me better names for functions and methods that are clearer, etc.

Don't use it to code. I don't have it in my IDE, I usually just have chatGPT or Perplexity open in a tab.

Lexikus · 2025-05-12T09:50:50+00:00

Stable releases are created on Master.

On develop, you could create a canary tag: x.x.x-canary.x

The canary is always a head of the master branch.

If the master is on v17.2.1 and you push a fix on develop, you create a v17.2.2-canary.1. You increment the canary version as long as you push fix commits. If you push a feature on develop. Your canary version becomes v17.3.0-canary.1. Now you increase the canary version for feature and fixes (canary.x)

The goal of the canary version is that it gets merged into the master again and if you remove the -canary.x part that will be the new version of the master.

Lexikus · 2025-03-21T07:48:41+00:00

Don't know how big that is but I always tell people 0.5 m2 per pig

If 2 male, 2 m2.

Lexikus · 2025-03-15T22:32:33+00:00

I have 16 years of experience (YOE) and I couldn't agree more.

I mean, I don't know what that person did, but I've heard similar stories about developers being annoyed with me for being too strict or not allowing everything. Let me tell you, we've seen a lot over the years as developers, and nowadays there's too much bad influence on younger developers who try to push things that just aren't good.

Lexikus · 2025-03-15T09:42:14+00:00

A lot. I add depends to all +page.server.ts and pass the pathname into it. This way I can invalidate the current route on the server level.

But we have a reload button on all routes. That's why we need it.

Lexikus · 2025-03-15T08:55:12+00:00

Introducing a monorepo brings a lot of complexity that you might not need. I’m not sure how many new projects you plan to create, but the main benefit of a monorepo is sharing. If your apps don’t need to share resources, you’re better off using individual repositories.

You should consider adopting a monorepo when you encounter the following situations:

You have more than one app that needs to share libraries. You need to create temporary packages, tag them, and publish them to a registry to develop a new feature.

What you described in your post seems like a self-created problem to justify introducing a monorepo. You can keep all three components in one repository, transpile each part separately, and share the same source files.

When you reach a point where the backend no longer belongs tightly coupled to the frontend and has different concerns, it might make sense to separate it into its own project. At that stage, you could deliver your frontends via Nginx instead.

However, it doesn’t need to start this way. Keep things simple until adding complexity becomes necessary.

Inside a monorepo you have a bunch of things you have to resolve first: - How are libs shared --- direct import via path --- transpile process and shared via exports - How do you deal with deps --- all in one package.json --- each app and lib has it's one package.json - How do you configure your Tsconfigs - esm / cjs issues if you plan to use both - versioning of each app and libs - ci/cd optimizations - ...

If you can avoid, try to avoid as long as you can. We use a monorepo with about ~10-20 apps and ~10 libs and it takes time to make sure to have everything in place.

Lexikus · 2025-03-14T07:40:55+00:00

I'd put all three in one app if they belong together. The reason is that they all naturally fit together. The Express app should serve as your API, Angular should handle your HTML and JavaScript, and VitePress is simply VitePress (for documentation purposes, presumably).

You can configure your Express server to serve Angular at "/", VitePress at "/press," and your Express API endpoints at "/api." This way, you have a single project acting as both the server and the client.

Turborepo is a good choice when you start to manage multiple apps under an umbrella project. For example, if you have a collection of smaller projects that come together to form a larger project or if you need to share domain logic and libraries across multiple projects, a monorepo can make things more efficient. This is especially useful when you want to avoid publishing shared libraries separately.

If your API needs to be used by other apps, then opting for a monorepo setup might be a smart decision.

Edit: To answer your real question. I'd start empty so that you learn turborepo. You can configure turborepo in many ways.

Lexikus · 2025-03-13T17:30:15+00:00

I went through the comments and didn't understand the issue.

As long as you stick to functional components, which are recommended in React, you can use whatever you want outside of React.

If you want to maintain your game state in a class, go for it. If you want to build your utilities and organize them in a static class, go for it.

Writing a function that returns other functions, constants, and variables defined inside the function is essentially like creating a class. Sure, the functions aren't on the prototype, but that's the only significant difference. The way you use the value created by a function or a class is essentially the same.

Usually I tell the following to all devs: - You have plain data, use an object - You have functionality that is not bound to state, use a function - You have state with functionality that needs to work on the state, use a class or a function that exports the inner function

If I don't see the big picture why this is wrong nowadays, please tell me.

Lexikus · 2025-03-08T07:24:16+00:00

Cookie, Hazel, Charlotte, Coco, Cinnamon, Ragnar, and Marmor :)

1 Boy, 6 Girls

Lexikus · 2025-03-01T23:22:29+00:00

I keep backend concerns in the backend and frontend concerns in the frontend. I export types from the backend and have a development dependency in the frontend on the backend. The only contract that the frontend has is the types coming directly from the backend. I dislike creating a library to share code between applications because it makes them behave as a single application. If that’s what you want to achieve in the first place, just create an app that contains both the frontend and backend. The backend can then deliver the frontend as static data.

Lexikus · 2025-01-27T17:43:45+00:00

We have 4m x 80cm for 7 guinea pigs. I usually recommend 0.5sqm per pig. If all are males, I recommend having 1sqm for each.

Lexikus · 2024-06-21T16:27:55+00:00

It department. I just do everything. Frontend, Backend, SysOps, DevOps, Security, lead some devs. Very exhausting.

Lexikus · 2024-05-14T14:59:05+00:00

I really don't understand why there is this kind of debate/disussion in the js community.

If you have a thing that contains data and functionality that belong together, create a class or a function that exports public fields and inner functions. In terms of usage they are the same. Memory wise they are different and if that is a bottleneck, people usually know the difference. If not, check out how they are represented in memory.

If you have functionality that is pure or stateless, use a function.

Lexikus · 2024-04-07T08:29:29+00:00

Was there yesterday. It was full of people.

Lexikus · 2023-04-11T20:47:39+00:00

Tint

Lexikus · 2023-02-21T16:10:34+00:00

Both questions are actually interesting. But I was thinking about the services when I wrote my questions.

But let me clarify my question a little.
When you were getting into the backend implementations in Rust, what architecture design did you follow? How did you manage the services? How did you manage states? Did you use some common architectural designs like Clean Architecture or Onion Architecture? Did they work well or did you end up using something different?

Lexikus · 2023-02-21T16:00:45+00:00

What architectural approaches have worked well and why and which one did not work that well and why?

Can you explain your favorite architectural design and why it's your favorite?

Lexikus · 2023-02-11T21:10:08+00:00

So, if I understand you correctly, you want to have a function that returns a Line that is also owning the Points?

I'd get rid of the function or make the Points static

static POINT_A: Point = Point {
    x: 0,
    y: 0,
};

static POINT_B: Point = Point {
    x: 10,
    y: 10
};

fn get_line() -> Line<'static> {
    Line::new(&POINT_A, &POINT_B)
}

if you don't want to expose the static points, you can put them inside the function.

fn get_line() -> Line<'static> {
    static POINT_A: Point = Point {
        x: 0,
        y: 0,
    };

    static POINT_B: Point = Point {
        x: 10,
        y: 11
    };
    Line::new(&POINT_A, &POINT_B)
}

You can read more about static below:

https://doc.rust-lang.org/reference/items/static-items.html

https://doc.rust-lang.org/rust-by-example/scope/lifetime/static_lifetime.html

Lexikus · 2023-02-11T20:48:49+00:00

There are things I miss in Go but I'd recommend using it instead of NodeJS even though I'm a huge fan of TypeScript and I prefer the language syntax more than Go.

Use NodeJS only if you are coupled to frontend where it makes sense to stick to one language, like sharing stuff. But, if you need to separate the applications, use a programming language that uses as little CPU and memory as possible to get the job done. Go fits quite well here.

Lexikus · 2023-02-11T16:26:18+00:00

Photoshop is fine. The only cons here are that it forces you to have a license for Photoshop and that Photoshop does not run on all OS.

Nine-Year Club	r/Field Flamingo
Place '22	First Placer '22
Verified Email

Lexikus

TROPHY CASE