-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to @matteo.collina/dateformat #235
Conversation
The dateformat maintainers decided that the v5.0.0 release would be ESM-only. Give the current stance of keeping the pino ecosystem to CJS for the time being, I do not think it is a safe long-term to depend on this library. Therefore I forked it.
What is the benefit over just pinning to 4.x? |
The benefit is that this new library could actually be maintained and not pinned in the past. |
Note that pinning to v4 only is correct and will get the job done for the time being. |
I'm concerned about tracking upstream maintenance. This is a very seldomly updated module. Think it will be difficult to realize improvements have been made and to port them to the fork. Can we open an issue upstream to ask them to reconsider? |
@jsumners They already did proper semver and pushed the change to a new 5.x branch. Considering the uptake in ESM usage lately, I don't think asking them to consider dropping ESM entirely is a fair ask. |
At best we can send PR for integrating one of the dual publishing solutions, I guess. |
That wasn't my suggestion. I suggest maintaining compatibility instead of needlessly breaking the community. |
Posted felixge/node-dateformat#169 |
Thanks. Let's see what outcome we get before proceeding with this path. |
The dateformat maintainers decided that the v5.0.0 release would be
ESM-only. Give the current stance of keeping the pino ecosystem to CJS
for the time being, I do not think it is a safe long-term to depend
on this library. Therefore I forked it.