Allow literal initializers of readonly properties in declaration files#26313
Conversation
sandersn
left a comment
There was a problem hiding this comment.
One refactoring comment to address before checking in.
Also, for an old PR like this, you should probably merge from master before merging to it. I forgot about this last week and broke the build.
| return grammarErrorOnNode(node.initializer, Diagnostics.Initializers_are_not_allowed_in_ambient_contexts); | ||
| } | ||
| } | ||
| if (node.initializer && !(isConstOrReadonly && isStringOrNumberLiteralExpression(node.initializer))) { |
There was a problem hiding this comment.
I'm pretty sure you can move this inside the preceding if, as well as const isConstOrReadonly = ... above.
Then it would be worthwhile to invert the node.initializer check and return early.
| !!! error TS1036: Statements are not allowed in ambient contexts. | ||
|
|
||
| export var v1 = () => false; | ||
| ~ |
There was a problem hiding this comment.
How is this readonly declaration?
There was a problem hiding this comment.
It's not, the error span location was just normalized for the initializer forbidden error to always be on the initializer instead of sometimes on the initializer and sometimes on the equals token.
There was a problem hiding this comment.
@weswigham makes sense. Sorry somehow I perceived as error removed. My bad.
|
@weswigham Thanks for the feature. Any chance you can take a look at this issue of ours and offer some advice on what you think is the best way forward? |
|
Issue #15881 talks about type widening of readonly properties in classes. Will this PR solve the widening of readonly properties of object literals as well? For example: interface IColors {
readonly [k:string] : string
}
const COLORS : IColors = {
red: "#f00"
}
interface IBasicReduxAction = {
readonly type: string
}
const someAction: IBasicReduxAction = {
type:"SomeActionType"
}After this release should the type of COLORS.red be recognized as "#f00" and the type of someAction.type be recognized as "SomeActionType"? |
And use them in declaration emit when required to preserve the widening behaviors of certain literal types.
Fixes #15881
Note: This also normalizes where the error span is placed for the ambient initializer error between variable declarations and properties - it is now always on the expression, rather than split between the expression and the
=token.