In the Sheet interface (and similar type definition in the WorkSheet interface), we always get the type any unless we use one of the "special keys". The CellObject | SheetKeys part is actually of no use for the developer, since it gets evaluated to any when any is added to the type union.
any is usually considered something to be avoided in typescript, so it would probably be better to use unknown if there really is a need to support more than the types already defined. However, this would need to be accompanied with type predicates for CellObject, all SheetKeys types as well as all WSKeys types. That would allow typescript users to easily feel confident about the cell type they're working with.
I can create a PR for this if it's of any interest. It would be a breaking change for typescript users though, since they would get static type errors if they accessed a cell without asserting or type guarding themselves.
Maybe there are other solutions, such as creating different get-methods depending on if it's a CellObject or something else, but I think this is the simplest solution.
Due to this type definition:
[cell: string]: CellObject | SheetKeys | any;In the
Sheetinterface (and similar type definition in the WorkSheet interface), we always get the typeanyunless we use one of the "special keys". TheCellObject | SheetKeyspart is actually of no use for the developer, since it gets evaluated toanywhenanyis added to the type union.anyis usually considered something to be avoided in typescript, so it would probably be better to useunknownif there really is a need to support more than the types already defined. However, this would need to be accompanied with type predicates forCellObject, allSheetKeystypes as well as allWSKeystypes. That would allow typescript users to easily feel confident about the cell type they're working with.I can create a PR for this if it's of any interest. It would be a breaking change for typescript users though, since they would get static type errors if they accessed a cell without asserting or type guarding themselves.
Maybe there are other solutions, such as creating different get-methods depending on if it's a CellObject or something else, but I think this is the simplest solution.