noPropertyAccessFromIndexSignature does not affect object literals

[concavelenz]

Bug Report

🔎 Search Terms

noPropertyAccessFromIndexSignature

🕗 Version & Regression Information

4.2+

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?noPropertyAccessFromIndexSignature=true#code/FAGwpgLgBBYM4QFxQN4G0CWA7AJmAHoggE7YDmAukRKVmQL5QC8qwU7UA9J1AO5h8AhlmgQAFhjgwA9lABGAgMaCArmTHQ5ATyhZpABWLSADmGIQtAQUWL4cAGJGAtgElcBAMoYyWQRBXEYAA08irQGOFwWADkEAB0bByCcorI0RLRQYnseABmaWJgICDSmcD0ANzAwIrSWHDS4HElZAAUsAhxyYoAlFW19Y1gzdJtHfF5fTV1DU0t7fAQaNHd0RRTA7PD8+PLeWt9QA

💻 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.

[andrewbranch]

This would both prevent logic errors and improve compatibility with Closure Compiler's ADVANCED optimizations.

Can you expound on each of these motivations?

[concavelenz]

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. noPropertyAccessFromIndexSignature is 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]

Similarly, object destructuring assignment is similar to property access, I would expect that destructuring an index signature would also give an error with noPropertyAccessFromIndexSignature:

type Dictionary = Record<string, string>;

let test: Dictionary = {
    // we want this to be caught by noPropertyAccessFromIndexSignature, but it isn't.
    abc: 'hi',
    def: 'hello',
};

// This is equivalent to getting test.abc, so should be an error
const {abc} = test;
// This is preferred
const {'abc': abc1} = test;

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]

@andrewbranch Where would I find the justification for noPropertyAccessFromIndexSignature?

[andrewbranch]

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]

ic since @Kingwl contributed #40171, I shouldn't expect the core TypeScript team to take an interest in this, I suppose.

[andrewbranch]

IIRC, @DanielRosenwasser is pretty enthusiastic about this flag. Personally, I think it belongs in a linter.