chore(tsconfig): enable noUncheckedIndexedAccess
#168
Conversation
🦋 Changeset detectedLatest commit: 284bdd0 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
examples/src/stt.ts
Outdated
| @@ -25,7 +25,7 @@ export default defineAgent({ | |||
| const recvTask = async () => { | |||
| for await (const event of sttStream) { | |||
| if (event.type === stt.SpeechEventType.FINAL_TRANSCRIPT) { | |||
| console.log(event.alternatives[0].text); | |||
| console.log(event.alternatives[0]!.text); | |||
There was a problem hiding this comment.
is it safe to assume that final transcript will have event.alternatives populated under all circumstances with at least one element?
There was a problem hiding this comment.
yes because we check for it inside the STT class. this is a one-or-more array
There was a problem hiding this comment.
we could define it as a one-or-more array on the typescript side then with alternatives: [elementType, ...elementType[]]
There was a problem hiding this comment.
well actually not quite. it's an empty array in case of {START,END}_OF_SPEECH because it's unused and it's easier to make it empty than have some sort of complicated typescript type depending on enum value for this. but for final transcript it is guaranteed. maybe i can make alternatives |undefined and then the ! would be on it instead for better readability
| @@ -122,7 +122,7 @@ export class ProcJobExecutor extends JobExecutor { | |||
| this.#proc!.send({ case: 'initializeRequest', value: { loggerOptions } }); | |||
| await once(this.#proc!, 'message').then(([msg]: IPCMessage[]) => { | |||
| clearTimeout(timer); | |||
| if (msg.case !== 'initializeResponse') { | |||
| if (msg!.case !== 'initializeResponse') { | |||
There was a problem hiding this comment.
| if (msg!.case !== 'initializeResponse') { | |
| if (!msg || msg.case !== 'initializeResponse') { |
Not sure if doing ! is temporary to unblock this PR and we are tackling this later, but I do prefer to just do safety checks instead of depending on ! to guarantee not having runtime issues
In this case, I know msg should always be defined, but in the case msg is nullish anyways, we should probably throw an error?
There was a problem hiding this comment.
i don't think we should recover in any way from this. this would signify a serious breakage that should probably throw ugly javascript errors rather than quietly/silently continuing on
There was a problem hiding this comment.
there's not much to add here with our own error that JavaScript wouldn't complain about anyway, regardless
There was a problem hiding this comment.
there's not much to add here with our own error that JavaScript wouldn't complain about anyway, regardless
Oh definitely agree, makes sense that the runtime error would accomplish the same thing 😄 - sounds good this is nice!
Co-authored-by: Gavin <gavinchingy@gmail.com>
used
!for places where we either check earlier, or we know for absolutely certain that there's gonna be a value.