Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

AugustinMauroy
Copy link
Member

@AugustinMauroy AugustinMauroy commented Oct 26, 2024

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

  • All test should pass
  • Website should display correctly (use Vercel preview)

Check List

  • I have read the Contributing Guidelines and made commit messages that follow the guideline.
  • I have run npm run format to ensure the code follows the style guide.
  • I have run npm run test to check if all tests are passing.
  • I have run npx turbo build to check if the website builds without errors.
  • NA I've covered new added functionality with unit tests if necessary.

@AugustinMauroy AugustinMauroy requested a review from a team as a code owner October 26, 2024 15:49
Copy link

vercel bot commented Oct 26, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
nodejs-org ✅ Ready (Inspect) Visit Preview Oct 26, 2024 3:49pm

@AugustinMauroy AugustinMauroy requested a review from a team October 26, 2024 15:50
Copy link
Member

@ovflowd ovflowd left a 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?

@AugustinMauroy
Copy link
Member Author

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 next.dynamic, which is responsible for the entire content of the site. Because typescript offers type-checking which allows us to check that our code is correct and is supposed to help with the review.
We shouldn't all write in typescript in ‘wow that's typescript’ mode but see it more as a tool to limit errors.

Copy link
Member

@RedYetiDev RedYetiDev left a 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

@ovflowd
Copy link
Member

ovflowd commented Nov 16, 2024

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 next.dynamic, which is responsible for the entire content of the site. Because typescript offers type-checking which allows us to check that our code is correct and is supposed to help with the review. We shouldn't all write in typescript in ‘wow that's typescript’ mode but see it more as a tool to limit errors.

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.

Copy link
Member

@ovflowd ovflowd left a 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.

@AugustinMauroy
Copy link
Member Author

before closing, can we get opinion from other members of the team @nodejs/nodejs-website

Copy link
Collaborator

@bmuenzenmeyer bmuenzenmeyer left a 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.

Comment on lines +3 to +4
// NOTE: this file canot be a ts file
// because `nodevu` din't have typedefs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// @ts-expect-error - The addItem need a valide Item type
// @ts-expect-error - The addItem need a valid Item type

Comment on lines +12 to -15
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
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants