feat(compartment-mapper): expose extraParsers option

[boneskull]

Description

The extraParsers option is an optional mapping of file extension (without leading .) to parser name. Consumers can use it to associate a file extension with a specific parser, e.g., {"node": "bytes"} or override the default mappings.

The specific use-case is enabling creation of compartment map descriptors for Node.js native modules (e.g., index.node) without needing a parsers: {node: 'bytes'} property in the package.json of the package containing the native module.

Because we are unlikely to be the maintainers of any given package exposing a native module, we do not have control over its package.json; to add the needed parsers field would require forking or using patch-package or something else. With this change, the consumer can add extraParsers: {node: 'bytes'} to any supported API call.

The API calls supporting the new option should be any that end up calling link() in link.js; this is where the mapping is concatenated with the default set of parsers.

Upgrade Considerations

This is a backwards-compatible change.

[boneskull]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(compartment-mapper): expose extraParsers option #2190 👈
• feat(compartment-mapper): expose loadCompartmentForArchive #2189
• fix(compartment-mapper): fix ReadPowers-related types #2188
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @boneskull and the rest of your teammates on Graphite

[kriskowal]

I think my choice of "parsers" in package.json was a misnomer. I changed it to languageForExtension internally, but can’t bring myself to be that verbose in package.json. I could bring myself to be that verbose for the option, though. Would you consider fallbackLanguageForExtension? That’d clarify that it shouldn’t override a local choice.