feat(common)!: migrate from moment to moment-tiny

[ghiscoding]

• so I created yet another repo, it is very similar to moment-mini except that it includes both CJS and ESM builds (which actually both come from the Moment project itself), however moment-mini package only references the CJS build even they build both CJS & ESM nonetheless (more info can be found on the moment-tiny repo)

Note

The newest version of MomentJS introduced a breaking change via this PR even if they released it under patch, it really is a breaking change (more strict on 1-2 digits). I think what I could do to ease the pain would be to add a new strictDateParse (defaulting to true) so that user could avoid the breaking change. The reason not to use non-strict is mostly it's way too loose by default which is why I prefer strict by default but providing a date of 01/01/23 with D/M/YY should still be accepted and it was prior to that referenced commit. The strict mode is mostly used in the Date Sorting and Filtering

TODOs

• for the breaking change, another possibility is to provide not just 1 format but an array of formats that Moment will loop through internally for example ['M/D/YY', 'MM/DD'YY'] (however note that this could potentially impact perf unless 1st format is the correct one)
• similar to previous task, another way would be to add an option to disable strict mode (when filtering/sorting)

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[codecov]

Codecov Report

Attention: Patch coverage is 96.00000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 99.7%. Comparing base (3c22b3e) to head (0f1da01).
Report is 1 commits behind head on next.

Files	Patch %	Lines
packages/common/src/editors/dateEditor.ts	83.4%	1 Missing ⚠️
packages/common/src/filters/dateFilter.ts	87.5%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            next   #1456     +/-   ##
=======================================
- Coverage   99.8%   99.7%   -0.0%     
=======================================
  Files        197     197             
  Lines      21653   21652      -1     
  Branches    7066    7069      +3     
=======================================
- Hits       21589   21586      -3     
- Misses        58      60      +2     
  Partials       6       6             

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zewa666]

is there a different behavior now with the date parsing?

[ghiscoding]

for unknown reason the newer version of moment doesn't accept zero padding anymore and in some ways it makes sense though, If we look at their Format docs, it does show only 1 digit when using D or M. I could use DD or MM but I'm not sure if that would work and what I'm almost certain is that would probably fail in strict mode when zero padding is missing... I can give it another try tonight though

I guess that what you're saying is that because of this, I might have to wait until next major and advertise the possible strictness in next major, is that it?

ok so I went through all their recent PRs and found this commit introduced in v2.30.0 so it seems that it doesn't accept zero padding in strict mode only. I think I use strict mode when sorting and filtering

Sorting

slickgrid-universal/packages/common/src/sortComparers/dateUtilities.ts

Lines 8 to 16 in 5ab671b

	export function compareDates(value1: any, value2: any, sortDirection: number, format: string | moment_.MomentBuiltinFormat, strict?: boolean) {
	let diff = 0;
	if (value1 === value2) {
	diff = 0;
	} else {
	// use moment to validate the date
	let date1: moment_.Moment | Date = moment(value1, format, strict);
	let date2: moment_.Moment | Date = moment(value2, format, strict);

Filtering

slickgrid-universal/packages/common/src/filter-conditions/dateFilterCondition.ts

Lines 11 to 20 in 5ab671b

	export function executeDateFilterCondition(options: FilterConditionOption, parsedSearchDates: any[]): boolean {
	const filterSearchType = options && (options.filterSearchType || options.fieldType) || FieldType.dateIso;
	const FORMAT = mapMomentDateFormatWithFieldType(filterSearchType);
	const [searchDate1, searchDate2] = parsedSearchDates;
	// cell value in moment format
	const dateCell = moment(options.cellValue, FORMAT, true);
	// return when cell value is not a valid date
	if ((!searchDate1 && !searchDate2) || !dateCell.isValid()) {

[ghiscoding]

@zewa666 I gave it a try and it is as I thought, when having a date like 01/01/92 and M/D/YY will not pass in strict mode. I think I should keep using strict mode in my lib nonetheless... So it really looks like MomentJS introduced a breaking change without even knowing and for that reason, I guess I have no choice but to postpone it for the next major release in 2 months and mention this new strictness in the migration

[ghiscoding]

@zewa666 alright, so what I found is that to go around the more strictness parsing problem with the new MomentJS version, what we can do is to provide multiple formats via an array. So what I've done is to add 2 formats for all the date formats that are considered as short. For example with Field.dateUsShort, I'm now passing ['MM/DD/YY', 'M/D/YY'] so that the user can still pass dates with/without zero padding. However there are 3 things to note

1. I can only use 1 output format and so I will always prefer the format with zero padding MM/DD/YY
2. parsing with multiple formats is slower than passing a single format and the array order matters, so zero padding will be quicker
3. I use strict mode when filtering & sorting, another idea would be to loosen the parsing and not use strict mode but non-strict mode is often too loose and I prefer strict mode

More info can be found in this Moment doc:
https://momentjscom.readthedocs.io/en/stable/moment/01-parsing/04-string-formats/

[zewa666]

awesome feature. just need something like that for the paste handling

[ghiscoding]

wow you're not sleeping, I thought you would reply in a day or two 😋

awesome feature. just need something like that for the paste handling

do you mean for another feature like the copy handler or did you mean something else? Should I go ahead with the merge then? what is your thought on the subject? I guess I'll be ready for a beta version by next week :)

[zewa666]

kids just woke me up ;)

yeah we've just experienced during the POC that handling date pastes might be tricky as people usually have excel files and stuff whatever they found right into the grid. So having the combo of a couple of supported formats + a locale is a great option.

I think this is definitely good for merge.

going to have another week to focus on the grid in 2w so looking forward to incorporate the new releases and fixes 🎉

[ghiscoding]

yeah I wish that I could have switched to date-fns but it always seems that MomentJS is still the best and no other lib have all the bells and whistles of Moment.

So I might have a beta by next week but it's still earlier than Angular 18 (which is scheduled for around May 20), however I will still make it the new minimum version requirement. I'm quite happy with the switch to pure CSS SVG, the Dark Mode is looking so so much better now :)

[zewa666]

dont look at me, still using moment and numeral in most projects bc it just works and the size overhead is ignorable in enterprise internal only apps. 😅

[ghiscoding]

I totally agree with all of that

[zewa666]

hah thats a nice coincidence. we just installed moment yesterday for the date parsing of our dynamic column formatstrings and adding cjs to the new vite build felt so wrong 😅

I'm gonna give it a try as well

[ghiscoding]

hah thats a nice coincidence. we just installed moment yesterday for the date parsing of our dynamic column formatstrings and adding cjs to the new vite build felt so wrong 😅

I'm gonna give it a try as well

Yeah so as I mentioned in the other discussion, as per this Moment commit, they transpile to ESM but if you look at their package.json, it's not even linked anywhere (except jsnext:main which I have never seen before). I would guess that it's because they don't want to break their user base. So I simply cloned their repo, copied the ESM build (from min/moment.min.js location) and copied the root one which is CJS or UMD maybe and created a repo with that (I think moment-mini were doing the same anyway but just the CJS version which I'm not that interested except when Jest is running which is still CJS). I also provide a better exports in the package as well, so in theory it should work better with Vite (I haven't fully tested it though but I no longer see the CJS warning in Angular at least which was my goal)

[ghiscoding]

@zewa666 have you had a chance to try moment-tiny with Vite? It looks like the min JS that I thought was an ESM build is not after all and I'm still getting the CJS in Angular and need to add it to allowed CJS. So I'm not sure if it's worth the move in that case.

[zewa666]

just created a fresh new empty vite project, installed moment-tiny and it loaded it from the esm folder.

[ghiscoding]

@zewa666 yeah ok but that's probably just because I did add an exports entry for ESM, however what I'm saying is that the build (file) in itself doesn't seem to be ESM at all because Angular still complains that it's CJS and for Jest I still have to use this ESM mock below for my unit tests to work (notice the use of __esModule: true which is to simulate an ESM package in a non-ESM package).

But anyway, does this new package help at all with Vite? is it better than using Moment (or moment-mini)?

slickgrid-universal/test/jest-global-mocks.ts

Lines 41 to 45 in 3649484

	// Jest has a hard time with MomentJS because they export as default, to bypass this problem we can mock the require .default
	jest.mock('moment-tiny', () => {
	const actual = jest.requireActual('moment-tiny');
	return { __esModule: true, ...actual, default: actual };
	});

[zewa666]

oh ok I see. I'll give it a try with angular and see how it goes