I spent too much time debating this implementation with myself! The simple solution is to just add it as another method and leave it up to the user to decide if they wish to use it or not (without any TS-level validation, as in microseconds(): number). A more complex solution would be to create a separate .d.ts file that extends Time and change the manifest to include it for the platforms that implement microseconds. But that turns into an ugly build problem for consumers of it - for example, code using microseconds for ESP32 could would fail to build on simulator requiring breaking apart source files and separate manifest files, when otherwise you could have done a runtime check.
I ended up marking it optional (microseconds?()), which with TS strict on would require you to check (e.g. if (Time.microseconds) ...) but without strict it will just allow the access. This seemed to most closely match how the JS implementation works.
Added
microsecondstoTimetype definitions.I spent too much time debating this implementation with myself! The simple solution is to just add it as another method and leave it up to the user to decide if they wish to use it or not (without any TS-level validation, as in
microseconds(): number). A more complex solution would be to create a separate.d.tsfile that extendsTimeand change the manifest to include it for the platforms that implementmicroseconds. But that turns into an ugly build problem for consumers of it - for example, code usingmicrosecondsfor ESP32 could would fail to build on simulator requiring breaking apart source files and separate manifest files, when otherwise you could have done a runtime check.I ended up marking it optional (
microseconds?()), which with TS strict on would require you to check (e.g.if (Time.microseconds) ...) but without strict it will just allow the access. This seemed to most closely match how the JS implementation works.