Repository navigation
noPropertyAccessFromIndexSignature does not affect object literals #46435
Description
Bug Report
🔎 Search Terms
noPropertyAccessFromIndexSignature
🕗 Version & Regression Information
4.2+
- This is the behavior in every version I tried
⏯ Playground Link
💻 Code
let test: {[index:string]:string} = {
// we want this to be caught by noPropertyAccessFromIndexSignature, but it isn't.
abc: 'hi',
def: 'hello',
};
console.log(test.abc); // reported
console.log(test.def); // reported
console.log(test['abc']); // OK
console.log(test['def']); // OK🙁 Actual behavior
Unquoted string keys are allowed when assigned to types with index signatures.
🙂 Expected behavior
Some mechanism for restricting the definitions of object literals so that only named properties are allowed to be provided without quotes ( {['somekey']: value} or {'somekey':value}. This would both prevent logic errors and improve compatibility with Closure Compiler's ADVANCED optimizations.
Activity
andrewbranch commentedon Oct 19, 2021
Can you expound on each of these motivations?
concavelenz commentedon Oct 20, 2021
I believe for logic errors, I believe this has the same motivations as
noPropertyAccessFromIndexSignature. For Closure Compiler's ADVANCED optimization mode, it differentiates between rename-able (optimizable) properties based on whether the property is "quoted". Quoted and computed properties are not renamed or eligible for optimization but "." access/unquoted properties are.noPropertyAccessFromIndexSignatureis helpful here as it encourage consistent use of "quoting". One of the teams we support is looking for the some degree of protection for object literals assigned to types with index signatures.https://developers.google.com/closure/compiler/docs/limitations#implications-of-global-variable,-function,-and-property-renaming:
Closure Compiler as you may know is used heavily at Google.
RussellSprouts commentedon Oct 25, 2021
Similarly, object destructuring assignment is similar to property access, I would expect that destructuring an index signature would also give an error with noPropertyAccessFromIndexSignature:
https://www.typescriptlang.org/play?noPropertyAccessFromIndexSignature=true#code/FAFwngDgpgBAIgSwMYgQewHYEMBOYYC8MASlEmjgCYA8AziDghgOYA0M9jLAfANzDAANlBAwQUegC54yVJlz4iAb2Aw1MAPQaYAd1g6sGUSAAWCWmLQwARrCRYArsxOjr+DGgAKONNBzgAQSQkCVoAMR8AWwBJDEooAA8AZQRmbBAHHCh2awdRBHzaDAByEAA6VXUsayRpYrNi1kq1eIAzOpMoQUE0RuAAX35gLRgAFTMLcxgoAEcHBAA3LGEjSzEJcuqkdloTNAdBShtYQ2mcHxxgcgx6GCUt-sJ1+n5r26VireLpLYBGR6I4heAjeaGEZR6zAAFEDNjUAJSvTC0MFQCFoaGwsptRFXZGo9GYjYAbU+NWKAF1caDwZCYSTim1KYigA
The Closure Compiler uses the quoting for all of these syntaxes to determine if the property name will be renamed.
concavelenz commentedon Oct 28, 2021
Andrew Branch (@andrewbranch) Where would I find the justification for
noPropertyAccessFromIndexSignature?andrewbranch commentedon Oct 28, 2021
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-2.html#--nopropertyaccessfromindexsignature. Following the link to the PR should turn up more discussion.
concavelenz commentedon Oct 29, 2021
ic since Wenlu Wang (@Kingwl) contributed #40171, I shouldn't expect the core TypeScript team to take an interest in this, I suppose.
andrewbranch commentedon Oct 29, 2021
IIRC, Daniel Rosenwasser (@DanielRosenwasser) is pretty enthusiastic about this flag. Personally, I think it belongs in a linter.