-
Notifications
You must be signed in to change notification settings - Fork 26.2k
refactor(compiler): account for pipes without names #61328
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
base: main
Are you sure you want to change the base?
Conversation
export declare class PipeWithoutName implements PipeTransform { | ||
transform(value: unknown): unknown; | ||
static ɵfac: i0.ɵɵFactoryDeclaration<PipeWithoutName, never>; | ||
static ɵpipe: i0.ɵɵPipeDeclaration<PipeWithoutName, null, true>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious, do you have thoughts this output appearing in projects using an older compiler version? I don't fully recall what our version guarantees here are (which way, backwards, forward etc.).
Likely simply not picking up the pipe metadata is the expected behavior here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm not entirely sure either, but I suspect that we don't support this sort of backwards compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's probably fine because there is no way to reference the pipe nicely "without" a name; but might be worth double-checking with others.
Worst-case, we could roll out changes to older compilers and error if we discover a nameless pipe when collecting metadata for a symbol via .d.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reporting an error when used with older compilers can be done by changing the minVersion
value of the partial declaration, that's what it's designed for.
} | ||
} | ||
PipeWithoutName.ɵfac = i0.ɵɵngDeclareFactory({ minVersion: "12.0.0", version: "0.0.0-PLACEHOLDER", ngImport: i0, type: PipeWithoutName, deps: [], target: i0.ɵɵFactoryTarget.Pipe }); | ||
PipeWithoutName.ɵpipe = i0.ɵɵngDeclarePipe({ minVersion: "14.0.0", version: "0.0.0-PLACEHOLDER", ngImport: i0, type: PipeWithoutName, isStandalone: true, name: "PipeWithoutName" }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, just to be safe, you did choose the name
to be still emitted for backwards compatibility of such "nameless pipe" partial compilation output, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I left it for backwards compatibility and because this is the name that the runtime will use to "match" pipes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Reviewed-for: public-api
Reviewed-for: fw-general
There were some discussions over whether we want to do the public API change now. I've dropped it for the moment and will leave the rest of the compiler code so that we can easily make the switch later. |
6daab46
to
9a873cc
Compare
Updates the compiler logic to account for pipe definitions that may not have names.
Updates the compiler logic to account for pipe definitions that may not have names.