Skip to content
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

Add opt-in behavior for custom transforms to support bundles #31301

Merged
merged 1 commit into from May 8, 2019

Conversation

rbuckton
Copy link
Member

@rbuckton rbuckton commented May 7, 2019

As an alternative approach to #29871, this PR addresses a backwards-compatibility issue when we added support for transforming Bundle nodes. Custom transformers have the type TransformerFactory<SourceFile>, as they only expect to receive source files. However, we assign them to an array of TransformerFactory<Bundle | SourceFile>[] and may inadvertently pass a Bundle to a transformer that is not able to support it.

To address this, I've added an opt-in mechanism where custom transform authors can return a CustomTransformer object or the existing Transformer<SourceFile> callback. Custom transformers are then wrapped in a callback that invokes the transformation based on whether it is a function (and correctly wraps it in a call to chainBundle), or an object (in which case the appropriate transformSourceFile or transformBundle methods are called).

Fixes #28310, #24459
Replaces #29871

Copy link
Member

@weswigham weswigham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, but that union type looks like a typo 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

API: Make public internal chainBundle
2 participants