Invalid date format
lukasschwab opened this issue · comments
System info
- MacOS 10.14
- xmigrate version:
@rxdi/xmigrate@0.7.38 - node version:
v13.3.0
Issue
The filenames created by xmigrate create do not correctly reflect the current date. When I created a migration this morning, the filename was
20204708104732-migration-name-here.js
More specifically, the month should probably be 01 instead of 47.
This happened to me once before, last year, yielding 20194504054532. That month is also incorrect (should not be 45).
Different members on my team do not have the same issue, though they seem to be running . xmigrate 0.7.18.
Investigation
It doesn't seem like my computer's/node's internal sense of date is broken:
$ node
> new Date(Date.now())
2020-01-08T23:35:40.025Z
I don't encounter this issue when I specifically install version 0.7.18:
$ npm i -g @rxdi/xmigrate@0.7.18
$ xmigrate create
[...]
💾 File: [...]/migrations/20200109013245-undefined.js
I am on it. Thanks for the issue! Will let you know later today if i have a solution but first i will try to reproduce the problematic scenario! Regards! @lukasschwab
@lukasschwab i have created pull request #9 related with the change.
I removed completely date-fns which was related with formatting the date specific. Basically i created simple function with native JS so i think we can forgot about this problem.
There is a issue also created date-fns/date-fns#1593 so they can track this down.
New version is published with the changes and you can install it like so:
npm i -g @rxdi/xmigrate@0.7.39
npm notice === Tarball Details ===
npm notice name: @rxdi/xmigrate
npm notice version: 0.7.39
Please try it out and if there are no problems related with it Close this particular issue.
Regards and best wishes,
Kristiyan Tachev (@Stradivario)
Installed 0.7.39 and the problem is resolved!
Thanks for the swift response and fix––excellent maintenance :)
This seems to be an issue again in version 0.7.47 on npm; I believe you changed the date format (inadvertently putting minutes in the place of months) before rolling that release: cf13923#diff-17b2be3256f7ebb9fa32b069a7ca0ab4c67bbf87b1b0793cc645704457a058ae
This file has since been updated, but that update has not been released: 77ffa37#diff-17b2be3256f7ebb9fa32b069a7ca0ab4c67bbf87b1b0793cc645704457a058ae
If you're confident in 77ffa37, I think the correct course of action is to just roll a new release? Though presumably you'll need to increment the version in package.json (which is back at 0.7.39 on master).
Oh my god... since before 3 4 months i switched to monorepo approach for all @rxdi infrastruture i think one of the deploys in which i tested out some things force pushed to some of the repositories till i notice it. I reverted all changes related with force pushing but i think i miss some...
Thank you for noticing it and regards!
I will fix it asap!
Monorepo
https://github.com/rxdi/rxdi-monorepo
I think xmigrate is the only repository which is not added to this monorepo since it can have separated releases than the rest of the system.
I have created a release pipeline when merging some pull request to master.
On every pull request there are tests which will be run for Node version 10 and 12.
There where a bug when seconds are less than 10 it shows them without zero prefix but it should be like this 01
Please check npm i -g @rxdi/xmigrate@0.7.49
Release section has 2 releases for now. I will try to make CHANGELOG to appears inside the drafted release.
This seems to be fixed in 0.7.50! Thanks again for the swift response.
@lukasschwab just to mention in the latest 0.7.51 release i have manage to add custom date format capabilities.
You can read more about inside Changelog https://github.com/rxdi/xmigrate/blob/master/CHANGELOG.md
I am thinking also to add some UI/UX using WebComponents.