Discussion for @nuxtjs/dayjs version 2

[nozomuikuta]

This PR is created based on conversation in #396, and is to clarify what we need to support Nuxt3, Nuxt Bridge, and to modernize the code base for the new era of Nuxt ecosystem. Modernization could include refinement of module API and DX since the result will be a major update.

---

TL;DR

I would like to know thoughts on the following topics.

• We should Nuxt 3 (I believe)
• Should we should Nuxt Bridge?
• Should we await for the new test utils, or should we prioritize fast release with dedicated manual testing?
• Is there things to add, refine, or delete in module API and DX in version 2?
• At first, what are the author(s) opinions?

---

Current situation

First of all, it is reported that @nuxtjs/dayjs module doesn't work with either Nuxt 3 (#376) or Nuxt Bridge (#387), which is of course the main focus for the time being.

Second, @nuxtjs/dayjs module doesn't provide composable(s) for composition API, which had been unavailable when this module was introduced. This will be a topic to discuss, and I don't have a strong opinion to be honest.

Third, the code base is (as far as I see) based on defacto standard of Nuxt 2 ecosystem (e.g., main logic in lib directory, defining declaration file separately). Nuxt team provides the new module starter template (nuxt/starter), so it will be a good time to migrate.

Fourth, the main logic of @nuxtjs/dayjs (i.e. lib/module.js) is written in JavaScript. Being written in JavaScript itself is not a thing that need to be "fixed", but Nuxt 3 ecosystem is now more TypeScript-friendly or even TypeScript-centric in most parts, so relying on it will be beneficial for future maintainability

Nuxt 3 support

With the new module template, supporting Nuxt 3 with the same API as the current version is just a few-hours task, except some aspects such as testing, as I already demonstrated in #396.

Nuxt Bridge support

Due to the lack of playground for Nuxt Bridge in the new module template, and some differences in Nuxt 2/3 API, we need more dedicated work on Nuxt Bridge support. We might be able to skip this task for now so that we can iterate the cycle of development more fast.

I would like to here your opinion for this point as well as providing composable(s).

Modernization as a part of Nuxt ecosystem

I mean it by modernization here to make @nuxtjs/dayjs module aligned with other Nuxt ecosystem, especially with Nuxt core modules. While we could make use of the legacy code base, I believe migration to the new normal will provide more benefits for us. For example, developers in the community will be more likely to be so confident to understand the code base and to contribute to this repository. Since no one can guarantee that the person maintain something forever, keeping parts of ecosystem aligned with others is what we can do for the community (cf. ADDRESSING ARCHITECTURAL ISSUES section of The process: Making Vue 3).

But, we should be aware of that Nuxt 3 ecosystem is still a work in progress. Some tools such as testing utils are not yet ready and stable. Here, we should make a decision about our roadmap for version 2 of @nuxtjs/dayjs module.

Fast release with few possible testing await core system mature, or even eclectic.

Again, I don't have a strong opinion. I'm just not willing to contribute based on authors decisions.

DX and API refinement

@danielroe suggested in #396 to provide composable(s) instead of injecting a plugin into Nuxt context.
I added module option validation logic in #396 for fast fail instead of runtime error.

What version 2 should provide and how is kinda open-question and needs feedback community.
I love to hear what features people need and implement them.

(By the way, I'm not sure whether there are differences between modules that is managed in nuxt-community organization and personal repository. Is the former more like community-driven one while the latter is owned by the person?)

[potato4d]

Based on the above, I propose to take the following flow

Create a dedicated branch for Nuxt3

Create a new branch named v3 in @nuxtjs/dayjs.
This would be an option to use a new scaffolding one, following the rules of the Nuxt v3 ecosystem.

The content of v3 will be published as @next to help users of v3.

I respect @nozomuikuta 's current work on how to proceed.

maintain master for Nuxt2

On the other hand, Nuxt3 is still in beta. As a community package, it must remain comfortable for existing Nuxt2 users.

Therefore, for the time being, master should be maintained as a repository for Nuxt2, and feature additions and bug fixes should be made.

[nozomuikuta]

Closed for the same reason as #396 (comment).