feat(package): export type guards

[partynikko]

This PR aims to solve #1011.

By exporting type guards consumers, like myself, can use said type guards to narrow down different audio nodes for different behaviours. I am currently experimenting with creating a declarative audio renderer, hence my need to narrow down declared nodes to their instances.

I have built and verified that I can import it and use it from another project.

[partynikko]

While I did not see this pattern in the source code, it's a neat way to re-export something without explicitly importing only to do export again.

[partynikko]

I just noticed that there are false positives amongst the type guards. For example, isOscillatorNode will return true for a BiquadFilterNode because of both detune and frequency being present in the latter.

isOscillatorNode(biquadFilterNode) // true

Have not tested others yet so there might be more? Will need to investigate, if this PR is to be merged. Let me know.

[chrisguttandin]

Hi @partynikko,

thanks a lot for making me aware of that buggy type guard. I created b6b2591 to make isOscillatorNode() return false when asked to check a BiquadFilterNode. Luckily it was only used for one specific check after isBiquadFilterNode().

standardized-audio-context/src/helpers/deactivate-active-audio-node-input-connections.ts

Line 36 in b6b2591

: isBiquadFilterNode(audioNode)

standardized-audio-context/src/helpers/deactivate-active-audio-node-input-connections.ts

Line 42 in b6b2591

: isOscillatorNode(audioNode)

I think this bug illustrates the problem with type guards very well. They don't really check if the logic actually makes sense. I'm not sure if exposing them would be a good idea?

Would instanceof checks work for your use case?

import { OscillatorNode } from 'standardized-audio-context';

if (oscillatorNode instanceof OscillatorNode) {
    // Yeah, it's an OscillatorNode ...
}