Material-ui-pickers: Date-io v2: Uncaught RangeError: Format string contains an unescaped latin alphabet character `n`

[moshest]

The @date-io library release a new version v2 that's break this module.

Please update docs and require install only version 1.X from @date-io in the meantime.

[nolandg]

For others struggling: if you installed @date-io@2.* you might see the error

Uncaught RangeError: Format string contains an unescaped latin alphabet character `n`

For now, downgrade to @date-io@^1.3.13.

[dmtrKovalenko]

Updated the docs. Also pinning this issue to make it easier to resolve the problem for v3 users

[matthewkwong2]

BTW, @date-io has explicitly stated that in their release Github page

[biostec]

Updated the docs. Also pinning this issue to make it easier to resolve the problem for v3 users

They do it!
Look here

[rvanmil]

Would it perhaps be possible to have the proper versions of the @date-io libaries listed as dependencies in this project instead of referring to a note in an installation guide? Tbh I think it's a bit odd we have to manually manage the @date-io dependencies because @material-ui/pickers doesn't specify the versions it requires (and so we now have two outdated dependencies in our projects which need to be pinned to the 1.x release for the time being).

[oliviertassinari]

@dmtrKovalenko Since recently, we can leverage the optional peer dependencies, e.g. https://github.com/mui-org/material-ui/pull/17211, that, I believe would warn if the version is not correct.

[oliviertassinari]

@dmtrKovalenko Alternatively, what do you think of changing the npm tags (to have latest point to v1 and next point to v2), until we complete the upgrade of the picker components?

[dmtrKovalenko]

Agree, but the main idea is that date-io is also used by other packages. We should not depend on date-io version.

Also there is a specific version of @date-ui/core that points picker to use ‘1.3.11’ and do the peer deps validation.

[rvanmil]

Forgive my ignorance 😊 but wouldn't it be easier to be able to specify the utils library you want to use, instead of providing it through dependency injection? For example: <MuiPickersUtilsProvider utils='moment'>

[dmtrKovalenko]

@rvanmil no, because it will lead to additional bundlesize and utils are directly importing moment or date-fns or any. So

[oliviertassinari]

Also there is a specific version of @date-ui/core that points picker to use and do the peer deps validation.

@dmtrKovalenko Nice, so we are good.

• Yarn/npm will warn about the peer dependency issue.
  https://github.com/mui-org/material-ui-pickers/blob/a865eaae2ddfc72864e410234d2adc5567c69d98/lib/package.json#L34-L35
  It's a shame developers have learned to ignore these warnings (myself included). I guess this is a good reminder that the install warnings aren't meant to be ignored.
  

• The problem is transient until we deploy a new version of the pickers that rely on the latest version of date-io.
• Updating the install commands in the documentation could help in the meantime.

---

On a side note, I have noticed two potential opportunities:

• The react team encourage the usage of prop-types as a dependency (not a peer) https://github.com/mui-org/material-ui-pickers/blob/689d7d33bdac5e649d4e5c6ca37f9f523c80b8cf/lib/package.json#L37
• The source of the component is in a lib folder, a folder that GitHub doesn't index, which makes searching the source with the UI impossible (I was querying for "@date-io"). I have learned about this aspect when working on Next.js, they have some of the sources in a lib folder, it was driving me crazy 😆.

[arturz]

Very weird shit, I have to admit.

[mauriciocarnieletto]

👀

[Yuri-Tiofilo]

Had the same problem, but I had access to this site
https://material-ui-pickers.dev/getting-started/installation,
which helped me install Date-io V1, enabling the use of datePicker.

[reoxb]

Dislike!

[haffedali]

I feel bad that I missed the note they left on their docs, it was even in bold LOL

[Temmermans]

How did you guys get it to work?
I tried downgrading like specified in this thread and followed the docs here but I still get the Format string contains an unescaped latin alphabet character n error.

[StefanJelner]

Is there any plan to fix this? It was reported on 5th of January and i am still getting this error. That's more than 2 months for something that prevents me from keeping my libraries up to date.

[dmtrKovalenko]

v2 of DateIO will not be supported for v3 of pickers.

[StefanJelner]

Sorry guys, but your stuff is not enterprise ready. I will have to look for alternatives.

[oliviertassinari]

I don't understand what paths developers are following to end-up in this configuration. @StefanJelner What step did you took to reproduce this problem?

@dmtrKovalenko Maybe we should circle back to https://github.com/mui-org/material-ui-pickers/issues/1440#issuecomment-572296065. There is a high number of upvotes (70) in a small time frame (3 months). I understand that you consider @date-io/core a different package, but I think that we should face reality, the vast majority of the usage comes from this picker (I haven't seen anyone yet not using with this picker, but I haven't paid a lot of attention).

[dmtrKovalenko]

@oliviertassinari we can easy make an additional release 3.2.11 to support date-fns v2. BUT this update is also must be major, so it will be 4.0.0
I really don't understand what is hard in just not update before v4 release of pickers?

[oliviertassinari]

I really don't understand what is hard in just not update before v4 release of pickers?

Agree, let's try to gain more feedback from users. I don't understand how the issue could have had 70 upvotes.

[Olaide-EO]

RangeError: Format string contains an unescaped latin alphabet character n

I got the same error while trying to use @material-ui/pickers

[oliviertassinari]

@Olaide-EO Do you have a reproduction?

[dmtrKovalenko]

@Olaide-EO try install 1.x version of @date-io

[oliviertassinari]

@nikosantis @lucasgabardo How did you end-up with this error?

[StephaneHo]

By the way

for cloning the project, it seems that @material-ui/pickers.git does not
work but @material-ui-pickers.git seems to work

Le mer. 25 mars 2020 à 15:50, Olivier Tassinari [e-mail]
a écrit :

@nikosantis https://github.com/nikosantis @lucasgabardo
https://github.com/lucasgabardo How did you end-up with this error?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mui-org/material-ui-pickers/issues/1440#issuecomment-603883752,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAMOOCH7R4WZVQUFUYASMTRJIK47ANCNFSM4KC3Z66A
.

[vasilii-b]

Had the same problem, but I had access to this site
https://material-ui-pickers.dev/getting-started/installation,
which helped me install Date-io V1, enabling the use of datePicker.

give this man a cookie

[matthewkwong2]

RTFM Jesus...

The release page of date-io literally says Do not update if you are using @material-ui/pickers v3.
https://github.com/dmtrKovalenko/date-io/releases

@material-ui/pickers@^4 is currently in beta so either uses that or downgrade to date-io@^1.

Keep posting "same here", "+1" contributes NOTHING.

[matthewkwong2]

I really don't understand what is hard in just not update before v4 release of pickers?

Agree, let's try to gain more feedback from users. I don't understand how the issue could have had 70 upvotes.

I don't understand too. Nowadays people just don't read...

[bmueller-sykes]

Perhaps this is obvious to everybody but me, but just so I'm clear...

There's a v4 of material-ui-pickers that's in the works? And that will resolve this issue? Is there a timeline for the release of v4?

[oliviertassinari]

@bmueller-sykes v3 works, v4 works.

[bmueller-sykes]

wait...what? @date-io/2.x works with @material-ui/pickers 3.2.10? I'm confused. I thought that expressly doesn't work. Am I being dense?

[oliviertassinari]

@bmueller-sykes Why do you want to use date-io v2 with pickers v3?

[bmueller-sykes]

@oliviertassinari Sorry, now I'm really confused. I use momentJS as my date library in my app overall. In my App.tsx file, I set up the pickers provider like this:

import { MuiPickersUtilsProvider } from '@material-ui/pickers';
import MomentUtils from '@date-io/moment';
<MuiPickersUtilsProvider utils={MomentUtils}>
rest of my app here
</MuiPickersUtilsProvider>

My relevant libs are:

"@date-io/moment": "1.3.13",
"@material-ui/pickers": "3.2.10",
"moment": "2.24.0",

So all I'm trying to do is keep all the libraries up to date.

I have a feeling that you're going to tell me I shouldn't be using @date-io/moment as the utils argument to MuiPickersUtilsProvider. My recollection is that I had to do things this way in order to integrate moment with the pickers. Maybe that's not true? I didn't intend for this to wind up as a support ticket, but here we are...

[oliviertassinari]

So all I'm trying to do is keep all the libraries up to date.

@bmueller-sykes Interesting! The good news is that the owner of date-io is the main author on the pickers, you are already up to date.

[bmueller-sykes]

I can't tell if you're making fun of me or not.

[dmtrKovalenko]

Closing issue, cause it was fixed in v4-alpha. If you are using v3, please lock version of date-io to 1.x
And wait for v4 stable :)

[oliviertassinari]

@bmueller-sykes I wasn't making fun of anyone. I want to reassure the developers that try to upgrade: it's not needed, there is nothing to gain, let's be patient :).