-
Notifications
You must be signed in to change notification settings - Fork 77
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
Use Intl.Locale internally #605
base: main
Are you sure you want to change the base?
Conversation
96375ad
to
7088385
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall quite happy with this. I'm a little surprised that checking the string length works, but indeed it apparently does, as the canonicalizations never change the subtag length. Some nitpicky line comments, and it looks like we may need to drop Node.js 12 CI tests.
I'd be fine inlining the constructor code that's here moved to separate functions, but this isn't a strong stylistic opinion, as long as the linter is satisfied.
const scriptCodeRe = "(?:-([a-z]{4}|\\*))"; | ||
const regionCodeRe = "(?:-([a-z]{2}|\\*))"; | ||
const variantCodeRe = "(?:-(([0-9][a-z0-9]{3}|[a-z0-9]{5,8})|\\*))"; | ||
function getVisibleLangTagLength(language: any, script: any, region: any) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should really be typed as string | undefined
; there should be no need for any
here.
return; | ||
} | ||
|
||
let [, language, script, region, variant] = result; | ||
this.language = result.language || "und"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How could result.language
ever be empty?
this.isWellFormed = true; | ||
} | ||
|
||
static fromComponents({language, script, region, variant}: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could/should this also use Intl.Locale
? The original included some normalizations that are included in Intl.Locale
processing, but they're dropped in these changes. Code here could construct an options bag to pass as the second arg of the Intl constructor, and then read the language/script/region from the result.
@@ -1,6 +1,7 @@ | |||
{ | |||
"extends": "../tsconfig.json", | |||
"compilerOptions": { | |||
"target": "es2020", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this enough? I was under the impression that TS only added the Intl.Locale
types in es2021
.
Alternative to #602 and #601 approach to fix #551 and #600.
I'm using
Intl.Locale
internally, but wrapping it for the masks use. This passes all tests and hopefully will make our alignment with ECMA-402 better.It also make us pass meta-zones and other BCP47 pieces using internal runtime parser.