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

Feature/typescript project #773

Merged
merged 15 commits into from
May 24, 2024
Merged

Feature/typescript project #773

merged 15 commits into from
May 24, 2024

Conversation

nicholasio
Copy link
Member

@nicholasio nicholasio commented May 20, 2024

Description of the Change

Removes the old TS projects and makes the default project (wp-nextjs) TypeScript based.

How to test the Change

Simply browse through the vercel preview url and ensure everything still works as expected

Checklist:

  • I agree to follow this project's Code of Conduct.
  • I have updated the documentation accordingly.
  • I have added tests to cover my change.
  • All new and existing tests pass.

Copy link

vercel bot commented May 20, 2024

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

Name Status Preview Comments Updated (UTC)
headstarwp ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 22, 2024 5:12pm

Copy link

changeset-bot bot commented May 20, 2024

🦋 Changeset detected

Latest commit: b66776f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@headstartwp/next Patch
@headstartwp/core Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.52 KB (🟢 -38 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.14 KB 133.66 KB 92.18% (🟢 -0.03%)
/404 404 B 123.92 KB 85.46% (+/- <0.01%)
/[...path] 7.13 KB 130.65 KB 90.11% (🟢 -0.03%)
/author/[...path] 5.67 KB 129.19 KB 89.10% (🟢 -0.05%)
/blog/[[...path]] 10.49 KB 134.01 KB 92.42% (🟢 -0.03%)
/category/[...path] 5.43 KB 128.96 KB 88.94% (🟢 -0.05%)
/search/[[...path]] 3.54 KB 127.07 KB 87.63% (+/- <0.01%)
/tag/[...path] 5.46 KB 128.99 KB 88.96% (🟢 -0.04%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

1 similar comment
Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.52 KB (🟢 -38 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.14 KB 133.66 KB 92.18% (🟢 -0.03%)
/404 404 B 123.92 KB 85.46% (+/- <0.01%)
/[...path] 7.13 KB 130.65 KB 90.11% (🟢 -0.03%)
/author/[...path] 5.67 KB 129.19 KB 89.10% (🟢 -0.05%)
/blog/[[...path]] 10.49 KB 134.01 KB 92.42% (🟢 -0.03%)
/category/[...path] 5.43 KB 128.96 KB 88.94% (🟢 -0.05%)
/search/[[...path]] 3.54 KB 127.07 KB 87.63% (+/- <0.01%)
/tag/[...path] 5.46 KB 128.99 KB 88.96% (🟢 -0.04%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.52 KB (🟢 -38 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.14 KB 133.66 KB 92.18% (🟢 -0.03%)
/404 404 B 123.92 KB 85.46% (+/- <0.01%)
/[...path] 7.13 KB 130.65 KB 90.11% (🟢 -0.03%)
/author/[...path] 5.67 KB 129.19 KB 89.10% (🟢 -0.05%)
/blog/[[...path]] 10.49 KB 134.01 KB 92.42% (🟢 -0.03%)
/category/[...path] 5.43 KB 128.96 KB 88.94% (🟢 -0.05%)
/search/[[...path]] 3.54 KB 127.07 KB 87.63% (+/- <0.01%)
/tag/[...path] 5.46 KB 128.99 KB 88.96% (🟢 -0.04%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.52 KB (🟢 -38 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.14 KB 133.66 KB 92.18% (🟢 -0.03%)
/404 404 B 123.92 KB 85.46% (+/- <0.01%)
/[...path] 7.13 KB 130.65 KB 90.11% (🟢 -0.03%)
/author/[...path] 5.67 KB 129.19 KB 89.10% (🟢 -0.05%)
/blog/[[...path]] 10.49 KB 134.01 KB 92.42% (🟢 -0.03%)
/category/[...path] 5.43 KB 128.96 KB 88.94% (🟢 -0.05%)
/search/[[...path]] 3.54 KB 127.07 KB 87.63% (+/- <0.01%)
/tag/[...path] 5.46 KB 128.99 KB 88.96% (🟢 -0.04%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Member

@tobeycodes tobeycodes left a comment

Choose a reason for hiding this comment

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

This is awesome

@@ -1,9 +1,13 @@
import { BlocksRenderer, YoutubeLiteBlock, ImageBlock } from '@headstartwp/core/react';
import { TwitterBlock, ImageComponent, LinkBlock } from '@headstartwp/next';
import { FC } from 'react';
Copy link
Member

Choose a reason for hiding this comment

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

question: why are we removing FC and therefore the return type?

Copy link
Member Author

Choose a reason for hiding this comment

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

FC is confusing, at some point it had children but in recent versions oof React types it doesnt.

I also don't like PropsWithChildren bc it makes children optional and sometimes we want to it be required. So for the most part, just typing the props is enough and actually allow us to better describe the component intention

Copy link
Member Author

Choose a reason for hiding this comment

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

and this one doesn't need children at all so IMO best to just type the props

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the explanation. I prefer using function anyway but usually use FC when defining a component as a const since it adds the return type. With function I'd usually add the return type ReactElement, etc

I like props with children because it uses ReactNode but I agree with you if you want to be more strict with requiring children then it is not a good choice.

Copy link

@kasparszarinovs kasparszarinovs left a comment

Choose a reason for hiding this comment

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

I've added a few comments throughout code, mostly as questions/clarifications :)

Love the amount of satisfies usage ❤️

A note on usage of interfaces. Is there a particular reason why you opt for using interfaces over types?
Although nowadays there's barely any differences between types & interfaces, there's a couple of things worth considering (I'm sure you're aware of these already):

  • Declaration Merging - ensure that this may not produce unwanted side-effects, unless you explicitly do want to use it.
  • Types are generally a bit more flexible, and can provide slightly cleaner syntax when using utility types and typeof for extracting types, using type aliases & unions, etc.

We generally tend to prefer using types, and stick to interfaces in specific situations:

  • when using with a class, for example if we write SOLID compliant code - our classes and sometimes also function parameters will use interfaces over types;
  • in scenarios where we know in advance that there will be a case of extending the base interface with additional properties, especially if it is exposed outside of its own project/library.

All in all, from our experience, types seem to provide slightly nicer DX and cleaner syntax, and interfaces we tend to leave for specific use-cases.

]);

return addHookData(settledPromises, { revalidate: 60 });
} catch (e) {
return handleError(e, context);
}
};
}) satisfies HeadlessGetStaticProps;

Choose a reason for hiding this comment

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

Love the use of satisfies 👌

Comment on lines 35 to 37
export interface AddHokoDataBaseProps {
[key: string]: unknown;
}

Choose a reason for hiding this comment

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

You may want to be careful with allowing wildcard props, unless you're explicitly planning to access them.

Copy link
Member Author

Choose a reason for hiding this comment

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

addHookData should be able to receive props that would then be passed to the page component in Next.js. This can be arbitrary props. This was mostly to allow TS to accept arbritary props and to infer the type from the passed props as well.

packages/next/src/data/server/handleError.ts Outdated Show resolved Hide resolved
"module": "esnext",
"moduleResolution": "node16",
"module": "ESNext",
"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve"

Choose a reason for hiding this comment

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

A couple additions that may be helpful, but not necessarily add too much strictness to the code. More around good coding practices rather than TS as such.

  • noFallthroughCasesInSwitch: true- Definition - ensures you are not skipping anything in a switch statement, and always at least provide a default option.
  • noImplicitAny - Definition - ensures you define as any explicitly, rather than implicitly assume it. This may add a bunch more changes to this PR however, but worth checking.
  • strictBindCallApply - Definition - can be helpful.
  • strictNullChecks - Definition - as the name implies, stricter null checks.
  • noUnusedParameters - Definition - also as the name implies, does not allow unused parameters to remain in code.

Copy link
Member

Choose a reason for hiding this comment

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

I think it would be nice to have a tsconfig.strict.json and tsconfig.json. The code in this repo would pass the strict tsconfig. Projects can choose whether they want to enforce strict TS or not depending on the engineers on the project.

Copy link
Member Author

Choose a reason for hiding this comment

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

noFallthroughCasesInSwitch and noUnusedParameters have very similar eslint rules in the 10up eslint config so I see no harm in adding it to TS. strictBindCallApply I think it's helpful and we don't write code using bind, .call very often so don't think it will make things too strict most of the time and strictNullChecks can help catch bugs so I think it makes sense.

noImplicitAny is the most strick one IMO but based on our convo we do want any to be a escape hatch for unexperience engineers so I'm fine forcing them to explicitly set any when they do need the escape hatch which would also make it easier to come back and update types later.

I don't think two configs would make sense as it would just add more confusion IMO.

@nicholasio
Copy link
Member Author

I've added a few comments throughout code, mostly as questions/clarifications :)

Love the amount of satisfies usage ❤️

A note on usage of interfaces. Is there a particular reason why you opt for using interfaces over types? Although nowadays there's barely any differences between types & interfaces, there's a couple of things worth considering (I'm sure you're aware of these already):

  • Declaration Merging - ensure that this may not produce unwanted side-effects, unless you explicitly do want to use it.
  • Types are generally a bit more flexible, and can provide slightly cleaner syntax when using utility types and typeof for extracting types, using type aliases & unions, etc.

We generally tend to prefer using types, and stick to interfaces in specific situations:

  • when using with a class, for example if we write SOLID compliant code - our classes and sometimes also function parameters will use interfaces over types;
  • in scenarios where we know in advance that there will be a case of extending the base interface with additional properties, especially if it is exposed outside of its own project/library.

All in all, from our experience, types seem to provide slightly nicer DX and cleaner syntax, and interfaces we tend to leave for specific use-cases.

interface has been mostly a personal prefernece. I'll update to use types as we haven't been very consistent with types versus interfaces and I prefer to favor consistency versus personal preferences.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.15 KB (🟢 -418 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.12 KB 133.27 KB 91.91% (🟢 -0.04%)
/404 404 B 123.54 KB 85.20% (+/- <0.01%)
/[...path] 7.16 KB 130.31 KB 89.87% (🟢 -0.01%)
/author/[...path] 5.67 KB 128.82 KB 88.84% (🟢 -0.03%)
/blog/[[...path]] 10.52 KB 133.67 KB 92.18% (🟢 -0.01%)
/category/[...path] 5.44 KB 128.59 KB 88.68% (🟢 -0.03%)
/search/[[...path]] 3.54 KB 126.7 KB 87.38% (+/- <0.01%)
/tag/[...path] 5.44 KB 128.59 KB 88.68% (🟢 -0.05%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.15 KB (🟢 -418 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.12 KB 133.27 KB 91.91% (🟢 -0.04%)
/404 404 B 123.54 KB 85.20% (+/- <0.01%)
/[...path] 7.16 KB 130.31 KB 89.87% (🟢 -0.01%)
/author/[...path] 5.67 KB 128.82 KB 88.84% (🟢 -0.03%)
/blog/[[...path]] 10.52 KB 133.67 KB 92.18% (🟢 -0.01%)
/category/[...path] 5.44 KB 128.59 KB 88.68% (🟢 -0.03%)
/search/[[...path]] 3.54 KB 126.7 KB 87.38% (+/- <0.01%)
/tag/[...path] 5.44 KB 128.59 KB 88.68% (🟢 -0.05%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.16 KB (🟢 -418 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.12 KB 133.29 KB 91.92% (🟢 -0.04%)
/404 404 B 123.56 KB 85.21% (+/- <0.01%)
/[...path] 7.16 KB 130.32 KB 89.88% (🟢 -0.01%)
/author/[...path] 5.67 KB 128.84 KB 88.85% (🟢 -0.03%)
/blog/[[...path]] 10.52 KB 133.68 KB 92.19% (🟢 -0.01%)
/category/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.03%)
/search/[[...path]] 3.54 KB 126.71 KB 87.39% (+/- <0.01%)
/tag/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.05%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.16 KB (🟢 -418 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.12 KB 133.29 KB 91.92% (🟢 -0.04%)
/404 404 B 123.56 KB 85.21% (+/- <0.01%)
/[...path] 7.16 KB 130.32 KB 89.88% (🟢 -0.01%)
/author/[...path] 5.67 KB 128.84 KB 88.85% (🟢 -0.03%)
/blog/[[...path]] 10.52 KB 133.68 KB 92.19% (🟢 -0.01%)
/category/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.03%)
/search/[[...path]] 3.54 KB 126.71 KB 87.39% (+/- <0.01%)
/tag/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.05%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

Copy link
Contributor

📦 Next.js Bundle Analysis for @10up/headless_framework

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page Size (compressed)
global 123.16 KB (🟢 -418 B)
Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Eight Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load % of Budget (145 KB)
/ 10.12 KB 133.29 KB 91.92% (🟢 -0.04%)
/404 404 B 123.56 KB 85.21% (+/- <0.01%)
/[...path] 7.16 KB 130.32 KB 89.88% (🟢 -0.01%)
/author/[...path] 5.67 KB 128.84 KB 88.85% (🟢 -0.03%)
/blog/[[...path]] 10.52 KB 133.68 KB 92.19% (🟢 -0.01%)
/category/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.03%)
/search/[[...path]] 3.54 KB 126.71 KB 87.39% (+/- <0.01%)
/tag/[...path] 5.44 KB 128.61 KB 88.69% (🟢 -0.05%)
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored.

@nicholasio nicholasio merged commit f6e005c into develop May 24, 2024
13 checks passed
@nicholasio nicholasio deleted the feature/typescript-project branch May 24, 2024 12:48
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.

3 participants