Add JS package with pattern parsers & serializers

[eemeli]

Adds the start of a JS library in parallel with the Python one, primarly to fulfil the needs of the Pontoon frontend.

Includes support for the following message pattern formats:

• android: Android string resources
• fluent: Fluent (without internal selectors)
• mf2: MessageFormat 2.0
• plain: Patterns without placeholders
• webext: WebExtensions (messages.json)
• xliff: XLIFF 1.2, including XCode customizations

The tooling for android and xliff depends on DOMParser, XMLSerializer, and related classes which are available in browser environments. The parser for fluent depends on the @fluent/syntax package, and the parser for mf2 depends on the messageformat package.

The primary entry points are:

import { parsePattern, serializePattern } from '@mozilla/l10n'

function parsePattern(
  format: 'android' | 'fluent' | 'mf2' | 'plain' | 'webext' | 'xliff',
  src: string,
  baseMsg?: Message,
  onError?: (error: ParseError) => void
): Pattern

function serializePattern(
  format: 'android' | 'fluent' | 'mf2' | 'plain' | 'webext' | 'xliff',
  pattern: Pattern,
  onError?: (error: SerializeError) => void
): string

These functions convert a flat message pattern between its data structure representation, and the format's serialized form. The data structure is the same as the one used by moz.l10n.message.message_from_json and moz.l10n.message.message_to_json.

A CI test action is included, and the package should be ready to publish on npm.

[mathjazz]

Have you thought about putting the JS library into a separate repository? It feels a bit odd to keep the Python version of the library in /moz/l10n when the JS version is in /js.

[eemeli]

Have you thought about putting the JS library into a separate repository?

Yes, but decided that having it in the same repo is the best way to ensure that the functionalities that are supported by both the Python & JS implementations continue to match. If we need to e.g. add a field to the JSON Schema or change how XLIFF patterns are represented, we can (and should!) apply the change to both implementations in the same PR.

It feels a bit odd to keep the Python version of the library in /moz/l10n when the JS version is in /js.

I can move the Python version to a python/ subdirectory after this lands, but didn't want to touch it in the same PR.

[mathjazz]

Looks good!

[mathjazz]

I can move the Python version to a python/ subdirectory after this lands, but didn't want to touch it in the same PR.

I'll leave that decision to you - mostly wanted to understand if you've considered a separate repo.