-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refracto: update more code to ts #7148
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI many of these files are intentionally done in plain JS -- so that they do not need to be transpiled by TypeScript.
There is no virtual benefit (necessarily) for having them in TypeScript. What's the motivation behind this change?
For me, it's ‘important’ to have them in typescript, for example |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM code wise, but I'd prefer to get other reviews before this is merged.
IMO there's not much difference between having these files in JS or TS. But, I'm curious to see some other opinions
Again, they should not be in TypeScript. There are reasons here, and I'm not going to approve a PR just because you feel that something needs to be refactored to TypeScript. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate your effort here, but sorry, I don't want this to get merged.
We shouldn't keep refactoring things on a whim, and there are reasons why certain things are not in TypeScript, they are internal utils and configuration files and hardly benefit anything from TypeScript.
before closing, can we get opinion from other members of the team @nodejs/nodejs-website |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are certainly parts of this PR that need polish (typos), TODOs, but I guess I'd like to better understand why more TypeScript is bad. I see some typings in here improving the code quality, while others simply shorten imports or replace jsdoc.
There is value here on both sides, but I don't yet understand Claudio's point of view.
// NOTE: this file canot be a ts file | ||
// because `nodevu` din't have typedefs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// NOTE: this file canot be a ts file | |
// because `nodevu` din't have typedefs | |
// NOTE: this file cannot be a ts file | |
// because `nodevu` didn't have typedefs |
}); | ||
|
||
const blogFeedEntries = posts | ||
.filter(post => post.categories.includes(category)) | ||
.map(post => ({ | ||
id: post.slug, | ||
title: post.title, | ||
// @TODO: use righ object type for date | ||
// wait https://github.com/nodejs/nodejs.org/pull/7143 to be merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is now out of date
author: post.author, | ||
date: new Date(post.date), | ||
link: `${canonicalUrl}${post.slug}`, | ||
})); | ||
|
||
// @ts-expect-error - The addItem need a valide Item type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// @ts-expect-error - The addItem need a valide Item type | |
// @ts-expect-error - The addItem need a valid Item type |
type RouteSegment = { | ||
locale: string; | ||
pathname: string; | ||
}; | ||
|
||
/** | ||
* This is a list of all static routes or pages from the Website that we do not | ||
* want to allow to be statically built on our Static Export Build. | ||
* | ||
* @type {Array<((route: import('./types').RouteSegment) => boolean)>} A list of Ignored Routes by Regular Expressions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this sorta implies their is a type we can import rather than define right?
// Renders a Link Component for `a` tags | ||
a: Link, | ||
// Renders a Blockquote Component for `blockquote` tags | ||
blockquote: Blockquote, | ||
// Renders a CodeBox Component for `pre` tags | ||
pre: MDXCodeBox, | ||
// Renders an Image Component for `img` tags | ||
// @ts-expect-error - MDXImage is a wrapper of Next Image so it's didn't have same props as HTMLImageElement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// @ts-expect-error - MDXImage is a wrapper of Next Image so it's didn't have same props as HTMLImageElement | |
// @ts-expect-error - MDXImage is a wrapper of Next Image so it doesn't have same props as HTMLImageElement |
Description
Refracto to have more file in ts:
it's allow to have type-check and it's "securise" our code
Note
There are still files written in javascript, either they are used in the
next.config.js
so they remain in js for the form but if SWC transpiles the ts.And there are also node scripts, but you'd need to have a loader or be in node 22.
So for the moment I'd rather do nothing for those.
Validation
Check List
npm run format
to ensure the code follows the style guide.npm run test
to check if all tests are passing.npx turbo build
to check if the website builds without errors.