Closed boneskull closed 1 month ago
[!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
This stack of pull requests is managed by Graphite. Learn more about stacking.
Join @boneskull and the rest of your teammates on Graphite
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.
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 aparsers: {node: 'bytes'}
property in thepackage.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 neededparsers
field would require forking or usingpatch-package
or something else. With this change, the consumer can addextraParsers: {node: 'bytes'}
to any supported API call.The API calls supporting the new option should be any that end up calling
link()
inlink.js
; this is where the mapping is concatenated with the default set of parsers.Upgrade Considerations
This is a backwards-compatible change.