Enable no-unchecked-record-access rule for devtools-core

[RishhiB]

ESLint Configuration Changes:

• Changed the rule for @fluid-internal/fluid/no-unchecked-record-access from "warn" to "error" in the .eslintrc.cjs file by removing the line

Needs Review:

• Modified variable declarations in DataVisualization.ts:
  • Added explicit type annotation EditSharedObject | undefined for editorFunction variable to handle potential undefined values
  • Updated type safety for editor function lookup from attributes type

@fluidframework/devtools-core: error during command 'eslint src' (exit code 1)
@fluidframework/devtools-core: /workspaces/FluidFramework-1/packages/tools/devtools/devtools-core/src/data-visualization/DataVisualization.ts
@fluidframework/devtools-core:   266:27  error  Implicit typing derived from '.editors[undefined]' is not allowed. 'undefined' is an index signature type and 'undefined' may be undefined. Please provide an explicit type annotation including undefined or enable noUncheckedIndexedAccess  @fluid-internal/fluid/no-unchecked-record-access

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

[jason-ha]

This is not a valid pattern. See numerous prior conversations.

[RishhiB]

I didnt know whether to make this change, allow the PR to pass and write this in the Needs review section, or to not make this change and not allow CI to pass. I will remove these changes from my PRs

[jason-ha]

Probably you should remove recognition of this pattern as acceptable to the lint rule - then maybe no one will try to use it and hide problems.

[RishhiB]

I can do this, but if I remove recognition of it, users will keep using the pattern, right? Isnt that what we are trying to avoid?

[jason-ha]

I don't know what you are asking. We thought that we could use the pattern of T | undefined to tell TypeScript to treat the variable as possibly undefined. But that doesn't happen. TypeScript ignores the undefined because [without noUncheckedIndexAccess] it thinks the result is always defined. Code says T | undefined and TypeScript sees T only.
Similar for ? - basically ignored by TypeScript and therefore meaningless.
If someone codes foo: T | undefined = and both the linter rule and TypeScript ignore the undefined part, then the linter will point out the issue and the code will have to be fixed. That is the result we want.