chore(gatsby): Use Typescript internally! #19923
Conversation
blainekasten
force-pushed
the
idea/typescript
branch
3 times, most recently
from
1fc295e to
a361d9b
Compare
|
FYI: #13436 |
blainekasten
force-pushed
the
idea/typescript
branch
from
a361d9b to
668d1bc
Compare
blainekasten
force-pushed
the
idea/typescript
branch
from
668d1bc to
3fd90e4
Compare
|
@moonmeister Thank you for the prior art! This is still a bit of an exploration ticket, but the core team is happy to explore this more now! |
|
@blainekasten good to know, I think it would be huge for the project. Thanks for taking this on. |
blainekasten
force-pushed
the
idea/typescript
branch
from
3fd90e4 to
00a3e21
Compare
blainekasten
force-pushed
the
idea/typescript
branch
9 times, most recently
from
2df0dee to
9aaa866
Compare
blainekasten
force-pushed
the
idea/typescript
branch
2 times, most recently
from
d22e36f to
ee4bf92
Compare
| report.panic(`There was a problem starting the development server`, err) | ||
| } | ||
| }) | ||
| const listener = server.listen(program.port, program.host) |
There was a problem hiding this comment.
typescript taught me that this callback function is not called with an error. But good news, we check for the port above and change the port to a new number. So this code was old and unused, but ts taught me to delete it!
blainekasten
force-pushed
the
idea/typescript
branch
from
ee4bf92 to
9d49c47
Compare
blainekasten
added
effort: med
type: maintenance
blainekasten
changed the title
blainekasten
force-pushed
the
idea/typescript
branch
6 times, most recently
from
fcac80d to
3ca2f57
Compare
There was a problem hiding this comment.
I've added some questions about guidelines and importing modules 👍 Thanks @blainekasten
| } = require(`../utils/webpack-error-utils`) | ||
| } from "../utils/webpack-error-utils" | ||
|
|
||
| type Cert = { |
There was a problem hiding this comment.
Do we want to write down guidelines when to use type or interface? I personally use interface for everything except if I need to use union, intersection, ...
There was a problem hiding this comment.
So I've had so many debates about this. There is no longer a practical difference besides syntax with types and interfaces. I'll switch to interfaces because that's more common in the typescript world. One benefit of interfaces is the practice of prefixing with I makes it obvious when importing whats a type and what's code.
e.g., import { Reporter, IReporter } from 'reporter';
There was a problem hiding this comment.
I've had so many debates about this
Haha, I can imagine. Honestly, I don't care, I just think something written about our way of using typescript would be great. If an eslint rule exists I would also use it to keep consistency.
remove flow from eslint Add typings for `got` fix lint drop commit test:check bring back webpack-utils Allow flow to live with typescript fix lint Improve check-ts script and add ts transformation to a second package Fix ts imports Fix gatsby-cli build script address PR comments
blainekasten
force-pushed
the
idea/typescript
branch
from
3ca2f57 to
d284dc6
Compare
sidharthachatterjee
added
bot: merge on green
Summary
This PR is the result of some exploration work to see what it would take to use TypeScript in gatsby source. This does not enable TypeScript for consumers. The goal of using TypeScript is to have the benefits of a type system to catch errors in our code paths that may not otherwise be easily found. This PR sets up the infrastructure to begin using TS and converts one file,
gatsby/commands/develop. There is a lot of organizational and process oriented discovery work to still resolve, but they are not blockers for this.What's next
With this PR we enable a slow migration of changing files to TS. The community could definitely get involved here! We'll need to decide some rules on how we want to approach typing our app before we can accept PRs. Things like, sharing types and what types we allow. Our goal is to simplify the types as much as possible, complex types usually mean complex code and a refactor is warranted.