Thanks to Good Free Photos.

Vetur had destroyed my enjoyment of programming. The experience it provides in the IDE is too degraded. Most of the refactoring features of the TypeScript code don’t work, there are bugs with monorepos, and so on. With my TypeScript developer team, we spend maybe 95% of our time on TypeScript code, 4% on the SCSS code (yes, we have a designer who write most of the CSS for us), and we can generously count 1% of our time spent on the HTML code. This is why an HTML container is a bad format to write a web application.

Therefore, a…


Thanks to Good Free Photos.

In this tutorial, I will show a way to validate, at runtime, the conformity of a JSON configuration file, in any existing project. We will be able to use our own TypeScript definition of the configuration types, with the help of TypeOnly.

Let’s start with a JSON configuration file

Let’s assume we have a Node.js project. In the main directory, the TypeScript source files are in a src/ directory, and the generated JavaScript files are in a dist/ directory. We also have a config.json configuration file like this one:

{
"tmpDir": "/tmp/data",
"httpServer": {
"port": 8212,
"hostName": null
},
"log": {
"level": "trace",
"prettyPrint": true
}
}

A TypeScript definition for the configuration file


Thanks to Good Free Photos.

I found a way to use Vuex stores in TypeScript without losing typing. It doesn’t require classes, so it is compatible with Vue 3 and the composition API.

With lightweight wrappers that are fully typed

At runtime, the library direct-vuex will create a wrapper around each getters, mutations and actions. We can use them from outside the store implementation.

So instead of writing:

store.dispatch("myAction", myPayload);

… we write:

store.dispatch.myAction(myPayload);

Or, instead of writing:

store.dispatch("myModule/myAction", myPayload);

… we write:

store.dispatch.myModule.myAction(myPayload);

Getters and mutations are accessible the same way:

store.getters.myModule.myGetter;
store.commit.myModule.myMutation(myPayload);

The types of these wrappers are correctly inferred by TypeScript.

How to create a direct store

The store can be implemented in the same…


Thanks to Good Free Photos.

With a guy on my team, we recently released a preliminary version of a side-project that could be promising. I wrote this article to present our work. And I start with: Why did we decide to create TypeOnly?

Because it’s not always possible to write DRY code with TypeScript…

TypeScript typing definitions are not available at runtime. Sometime this forces us to repeat ourselves, as in the following example:

type ColorName = "red" | "green" | "blue"function isColorName(name: string): name is ColorName {
return ["red", "green", "blue"].includes(name)
}

This kind of code is not ideal. There is an open discussion on Github related to this subject, and the TypeScript team…


Thanks to pixnio.

I created a common API for Node.js on top of two DBMS drivers. The API is inspired from PDO and JDBC. It’s named LADC for “a Layer Above Database Connectors”.

The project is still in alpha version. However I use it in my projects and it works fine. I need help from users to get feedback: Does the API really meet all common needs? Did you find any bugs? In addition, the help of contributors will of course be greatly appreciated.

Why a Common API Above DBMS drivers?

Above drivers? Unlike PDO and JDBC, the purpose is not to replace DBMS drivers. This project is designed to…


Make your work clean and neat

Why to bundle a npm package?

For cleanliness.

When a developer writes the code of a npm package, he distributes his code over several ES6 modules for convenience. But then, the only valid exported members of the npm package are those of the entry point.

Exported members from internal modules, unless the author knowingly uses this capability, should not be accessible from outside the package. Indeed, they are not guaranteed by the version system. And, in fact, a simple refactoring could break an external code that would call them.

Let’s imagine the following module intended for internal use in a npm package:

// internal-log.mjs
export function info(message)…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store