Description

This PR enables typescript's strictNullChecks for

• @lingui/cli
• @lingui/format-po
• @lingui/loader
• @lingui/message-utils
• @lingui/vite-plugin
• @lingui/extractor-vue
• @lingui/metro-transformer

Packages still not using strictNullChecks:

• format-po-gettext this package doesn't even have strict: true at this point, so it requires a heavy modernizing (in a separate PR)
• babel-plugin-lingui-macro - many patterns in the code hard to rewrite, currently benefits are not worth the effort, maybe re-attempt next time

The most importantly that all "lib" packages such as @lingui/cli and @lingui/conf now fully strict, that means rewriting "leafs" from dependency graph packages is unblocked.

null vs undefined

Many of the changes in the PR caused by null vs undefined change. There is a lot of debates in typescript and javascript community about when and what should be used. This become even more problematic with strictNullChecks because

type string | null | undefined is not assignable to string | undefined or vice versa string | null

So it's better to eliminate one or another and write consisently across codebase.

Many teams opted for the undefined only, for example typescript in theirs codebase uses it. The main reason for that is because undefined could not be complietely eliminated - it would pops up when property or parameter is optional, but null could be fully eliminated from the code base if you are not assigning it manually.

I also opted for undefined only, hence changes.

ExtractedMessageType vs MessageType and their corresponding ExtractedCatalogType and CatalogType

Now disticntion between them even more "distinct" and change the real code scenario Extracted* family used for messages produced by extractor, where versions without Extracted are corresponding for messages and catalogs from loaded catalogs.

What the diffrence? For example just extracted messages would not have a translation property, obsolete and extra, they are parts of the locally stored catalog.

And vice versa, ExtractedMessageType always have the placeholders and comments fields, even if they are empty, but catalog from disk could omit them.

So to further harden the typesafety this distiction was improved.

Breaking changes description

It's not intentionally breaking change, but changing the types might break something for anyone who used lingui internal types (custom integrations)

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Examples update

Fixes # (issue)

Checklist

• I have read the CONTRIBUTING and CODE_OF_CONDUCT docs
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)