dayjs VS ESLint

The fact that moment.js or day.js needs to exist in 2024 bothers me a lot.

Day.js (45.3k ⭐) — A minimalist library that offers an excellent API without much overhead. It is very similar to Moment.js but much smaller in size. It also supports plugins for additional features.

Day.js is a lightweight alternative to the now deprecated date and time handling library, Moment.js. It is written in JavaScript and uses a similar API to Moment.js. Day.js is sufficient for date operations such as parsing, manipulation, and display. It is designed for use on both the browser and the Node.js runtime.

Day.js is awesome for comparing dates! You just need to make dayjs objects from whatever dates you have. You can use the dayjs() function with different inputs and formats. Here’s an example:

Similar API to Moment.js: Day.js provides a familiar API, making it easier for developers previously using Moment.js to transition.

As web developers, we heavily rely OSS packages. One popular example is Day.js, a JS lib for parsing, validating, manipulating, and formatting dates. It's a widely-used alternative to Moment, with over 17mil weekly downloads on npm.

A critical bug was discovered in Day.js (see: https://github.com/iamkun/dayjs/pull/2118) causing incorrect date manipulation (add, subtract) when in UTC TZ. This could have severe implications for any project relying on Day.js for date-related functionality. However, the maintainer of the project appears to be unresponsive, leaving the bug unresolved and the future of the library uncertain.

This raises some important questions for our community:

- At what point should we consider a widely-used OSS project "abandoned" if the maintainer is unresponsive?

- Is forking the project the best solution, or should we first try to reach out to the maintainer through other channels?

- Are there established community guidelines around responsiveness expectations for widely-used OSS projects?

- What are successful examples of community-driven forks or maintenance after a maintainer stepped away?

I am very aware that many of these developers give their spare time for free for these projects, with little or no payment, and I am very thankful for all their work. This developer does get some money (a small amount?) through OpenCollective, and possibly also works for a company (in China?) that makes a UI library, which I think uses Day.js internally.

11. DayJs

DayJS has issues with its timezone plugin not compatible with Hermes engine https://github.com/iamkun/dayjs/issues/1942

Date.js

We have to install refine's support packages for React Table and React Hook Form. We are using Tailwind Heroicons for our icons, the Day.js library for time calculations and Recharts library to plot our charts for KPI data. So, run the following and we are good to go:

Repository: ESLint

For ESLint + TypeScript ESLint, with the new flat config eslint.config.js:

ESLint: JavaScript linting.

But what is a symbolic link exactly? It comes from programming and I often liken symbolic links to basic redirects but with greater stability. However, not every package needs a place in .bin. Packages like nodemon, webpack, gulp, eslint and create-vue are found in .bin because they need to be executed. On the other hand, packages like animate.css, swiper and express operate at the application layer, so you won't find them in .bin after installation. How does npm determine whether a package is executable or not? It's simple: by using the bin property in your package.json to specify the executable path. If your package is executable, you can set it accordingly. Let's take a look at prettier's package.json file

Eslint: It analyzes our code to quickly find problems. We will use the default setup provided by Vite.

A big part of my work revolves around JavaScript tooling, and as such it's important to keep an eye on the ecosystem and see where things are going. It's no secret that recently lots of projects are native-ying (??) parts of their codebase, or even rewriting them to native languages altogether. Esbuild is one of the first popular and successful examples of this, which was written in Go. Other examples are Rspack and Turbopack, which are both Rust-based alternatives to Webpack, powered by SWC ("Speedy Web Compiler"). There's also Rolldown, a Rust-based alternative to Rollup powered by OXC ("The JavaScript Oxidation Compiler"), but Rollup itself is also native-ying (??) parts of their codebase and recently started using SWC for parts of their codebase. And finally, there are Oxlint (powered by OXC) and Biome as Rust-based alternatives for Eslint and Prettier respectively.

Let's be honest - setting up tools for a new project can be a frustrating process. Especially when you want to jump straight to coding part. This is often the case with ESLint and Prettier, two popular tools in the JavaScript ecosystem that can sometimes interfere with each other when it comes to code formatting. Fortunately, there's a simple solution to this process, and it's called eslint-plugin-prettier.

Do you have the need to find and fix problems in your JavaScript? Then ESLint is for you. With over 120 million downloads each month, it's definitely one of the most popular projects out there. The latest version introduces a new configuration system, designed to simplify available configuration options. Old and deprecated rules have been removed, and a new configuration inspector has been added. Check out the blog for all the highlights, and a migration guide.

ESLint: A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript.

Automating code checks with static code analysis allows us to enforce code styling effectively. By integrating tools into our workflow, we can identify errors at an early stage, while coding instead of blocking us at the end. For instance, flake8 checks Python code for style and errors, eslint performs similar checks for JavaScript, and prettier automatically formats code to maintain consistency.