JSONata : $moment -> $dayjs

Core Development
,
1

During a recent conversation, @dceejay brought up that moment is no longer suggested.
Doing my own research, this certainly seems to be the case.

So I experimented, and I was able to add dayjs to the engine with little to no stress.

const dayjs = require("dayjs");
const utc = require("dayjs/plugin/utc");
const timezone = require("dayjs/plugin/timezone");
dayjs.extend(utc);
dayjs.extend(timezone);

....

expr.assign('dayjs', function(arg1, arg2, arg3, arg4) {
        return dayjs(arg1, arg2, arg3, arg4)
});

Screenshot 2024-09-08 at 21.14.01
Screenshot 2024-09-08 at 21.14.011278Ɨ465 27.5 KB

Is it of sound mind to add this in the next feature update?
to path the way of moving away from moment?

The API's are almost identical, adding it now - can open up the door to removing moment in a future major?

6 Likes
2

I've used dayjs previously in node-RED, and found it quite easy to use.
I particularly like it because it's just 2kB in size.

1 Like
3

I use it quite a bit, and become familiar with it fast, given the API is based on that from moment.

To me at least, its a no brainer to start the transition to dayjs, get it in early, allow time for the public to adapt, before removing moment in v5

4

I have been able to use dayjs by adding

    functionGlobalContext: {
...
        dayjs: require('dayjs')
    },

to settings.js
However, I cannot access utc and timezone. What does it mean to add this code "to the engine"?

const dayjs = require("dayjs");
const utc = require("dayjs/plugin/utc");
const timezone = require("dayjs/plugin/timezone");
dayjs.extend(utc);
dayjs.extend(timezone);

(In general, I'm still trying to understand adding packages with plugins to Node-RED. If anyone can point me to a document and/or tutorial I'd greatly appreciate it.)

5

You just add dayjs to the setup tab of a function and then access it.. that's it. No require needed.

6

you just add dayjs to the setup tab of a function and then access it..

I don't think it would work for change node, OP show.

1 Like
7

I missed the beginning of the thread and answered you as if you were doing the code in a function node since you mentioned functionGlobalContext which is the old method of gaining access to modules in a function (which is why I pointed you to the article)

8

Given this thread received a heartbeat!
Iā€™m eager to know if the core team have a view here?

Iā€™m happy to put up a PR to make it happen? (Along side $moment of course)

1 Like
9

Yes. I think moving towards day.js makes sense, as at some point moment will get deprecared

3 Likes
10

Happy for the PR but "alongside"? Bah! This is just more code to maintain. We are not great at depreciating things.

We may wish to explore introducing it via a setting that exclusively choses one or the other (not both) with the aim to remove Moment at some future point.

An alternative approach could be to drop moment and mimic its functionality using dayjs? for example moment.isMoment could be mapped to call dayJs.isDayjs however i am not 100% certain all functionality of moment can be so easily proxied to dayjs functionality.

Other ideas and thoughts welcome of course.

11

You could always mark it as about to be deprecated, then set a future version as the endpoint. Probably should be quite a while ahead though as some folk don't seem very good and updates. :slight_smile:

If Moment could be transparently replaced though, I guess that would be even better.

12

My plan was going to be add $dayjs() to the list (not touching $moment())
and for the project to start favouring day.js over moment - in view of it being removed in the future.

if I may @Steve-Mcl I'll PR the dayjs addition as the foundation?

13

There is no reason you cannot make a start TBF, but I would personally be against duplication without a clear path to final migration. Something agreed with clear outlines.

14

Here is my suggestion then. If you can squeeze dayjs in fairly quickly. Mark $moment for removal in Node-RED v5 as a potentially breaking change.

Maybe someone can even work out a way to automate a migration as well.

15

Initial PR raised.

4 Likes
16

Given the tiny library size of dayjs I wouldn't be worried about having both for a while. I think we should then announce that moment will be deprecated in Node-RED v5 and removed in v6.

3 Likes
17

Thanks, @Steve-Mcl.

Here is what I found. This goes in the Setup tab of a function node:

{3C87AFB2-BE62-49DE-8196-B3F37F3C2491}
{3C87AFB2-BE62-49DE-8196-B3F37F3C2491}946Ɨ662 27.3 KB

Then, use this code:

dayjs.extend(utc);
dayjs.extend(timezone);

I would fully support adding dayjs as a standard part of Node-RED. It takes a little adjustment, but since moment.js is deprecated, it is time to start moving on to something else.

2 Likes
18

I use the moment node alot. Does this mean that node will stop working eventually?

19

This is about built-in moment. The moment node will be unaffected.

20

It will eventually. But I wouldn't worry too much, I'm certainly not about to get rid of it and it looks like the MomentJS library isn't in a hurry to die either. There are rather a lot of other projects that still rely on it.

However, good news is that @fdecourt is working on a new node using DayJS that mirrors my old moment node as closely as possible. Hopefully it will be easy to switch over.

1 Like