add typescript type checking/emitting based on jsdoc strings #200
Conversation
sfishel18
force-pushed
the
just-enough-typescript
branch
from
925510e
to
5883575
Compare
sfishel18
changed the title
| value: parseFloat( | ||
| averageIntensity.data[device.country?.toUpperCase()] | ||
| ), | ||
| // TODO (simon) check that parseFloat can be safely removed here |
There was a problem hiding this comment.
question: the types i could find suggest that averageIntensity.data[device.country?.toUpperCase()] will always be a number, so parseFloat is unnecessary. are there cases where that could be a string?
| */ | ||
| async function loadJSON(jsonPath) { | ||
| const jsonBuffer = jsonPath.endsWith(".gz") | ||
| ? await getGzippedFileAsJson(jsonPath) | ||
| : await readFile(jsonPath); | ||
| return JSON.parse(jsonBuffer); | ||
| // TODO (simon) should we check that the parsed JSON is a list of strings? |
There was a problem hiding this comment.
question: typescript itself can't guarantee that what comes out of JSON.parse is actually a list of strings. would it be worth adding some runtime checking to validate?
| * @template {Record<string, number>} EnergyObject | ||
| * @param {EnergyObject} energyByComponent - energy grouped by the four system components | ||
| * // TODO (simon) check on this type for carbonIntensity | ||
| * @param {(number | boolean)=} carbonIntensity - carbon intensity to apply to the datacentre values |
There was a problem hiding this comment.
question: it looks like this param is being used as a boolean but is initialized to a number when not provided. i'm wondering if it should be initialized to false instead?
src/co2.js
Outdated
| const allAssets = []; | ||
| for (let asset of pageXray.assets) { | ||
| const domain = new URL(asset.url).domain; | ||
| const domain = new URL(asset.url).host; |
There was a problem hiding this comment.
question: is this change correct? typescript doesn't recognize that there is a domain property of a URL instance, but it's possible it's inferring the wrong URL type
|
@fershad / @mrchrisadams i think this is ready for a first look from you. i tried to hit the right balance between getting some maintainable types without adding too much complex typescript logic that might be a barrier to entry for contributors. but of course i'll defer to you on what that balance should be, so let me know if i should lean more toward the "fancy" typescript features or go in the other direction and make everything more explicit. specifically the "fancy" stuff i'm referring to is in the utility types at the bottom of in terms of leaning toward more complex typescript logic, what i had in mind was for methods like |
sfishel18
force-pushed
the
just-enough-typescript
branch
2 times, most recently
from
c3b4a2e
to
fbbeabf
Compare
…e, and some cleanup
sfishel18
force-pushed
the
just-enough-typescript
branch
from
fbbeabf
to
73ef44d
Compare
fixes #199