fix(deps): update dependencies (non-major) #1204

renovate · 2024-02-02T20:26:33Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@ant-design/icons (source)	`^5.2.6` -> `^5.3.0`
@codesandbox/sandpack-react	`^2.11.3` -> `^2.12.1`
@octokit/types	`^12.4.0` -> `^12.5.0`
@testing-library/jest-dom	`^6.3.0` -> `^6.4.2`
@testing-library/react	`^14.1.2` -> `^14.2.1`
@types/jest (source)	`^29.5.11` -> `^29.5.12`
@types/node (source)	`^20.11.9` -> `^20.11.19`
@types/react (source)	`^18.2.48` -> `^18.2.57`
@types/react-dom (source)	`^18.2.18` -> `^18.2.19`
antd (source)	`^5.13.3` -> `^5.14.1`
cypress (source)	`^13.6.3` -> `^13.6.4`
framer-motion	`^11.0.3` -> `^11.0.5`
next-seo	`^6.4.0` -> `^6.5.0`
postcss (source)	`^8.4.33` -> `^8.4.35`
postcss-preset-env (source)	`^9.3.0` -> `^9.4.0`
prettier (source)	`^3.2.4` -> `^3.2.5`
stylelint (source)	`^16.2.0` -> `^16.2.1`
yarn (source)	`4.0.2` -> `4.1.0`

Release Notes

ant-design/ant-design-icons (@ant-design/icons)

`v5.3.0`

Compare Source

codesandbox/sandpack (@codesandbox/sandpack-react)

`v2.12.1`

Compare Source

Bug Fixes

Theme state logic to account for non-prefers-color-scheme usage (#1082) (3fcd51d)

Features

Private NPM guidance update (#1079) (40ad726)

`v2.12.0`

Compare Source

Features

sandpack template type (#1075) (db8eba7)

2.11.3 (2024-01-17)

Bug Fixes

Update CodeMirror View when autoReload changed (#1059) (782c0c7)

2.11.2 (2024-01-11)

Bug Fixes

bump codesandbox-client and test new publish script (#1056) (1736185)

2.11.1 (2024-01-10)

Bug Fixes

add allow-downloads to iframes (#1054) (c038e13)

octokit/types.ts (@octokit/types)

`v12.5.0`

Compare Source

Features

add x-accepted-github-permissions (#609) (bc28bdc)

testing-library/jest-dom (@testing-library/jest-dom)

`v6.4.2`

Compare Source

Bug Fixes

Remove errant export of GetByRoleMatcher, fixing type checking in some TS configurations (#575) (a93c0c4)

`v6.4.1`

Compare Source

Bug Fixes

Export type TestingLibraryMatchers from "./matchers" (#576) (dd1c4dd)

`v6.4.0`

Compare Source

Features

Add toHaveRole matcher (#572) (f7dc673)

testing-library/react-testing-library (@testing-library/react)

`v14.2.1`

Compare Source

Bug Fixes

Update types to support all possible react component return values (#1272) (55e79c2)

`v14.2.0`

Compare Source

Features

add reactStrictMode option to enable strict mode render (#1241) (0880eba)

ant-design/ant-design (antd)

`v5.14.1`

Compare Source

🐞 Fix Steps cannot interact correctly when type="inline". #47406
🐞 Fix DatePicker & TimePicker arrow position not consider panel border radius distance. #47389
🐞 Fix Dropdown should not display when items is empty array. #47375
🐞 Fix Tag that should use defaultBg token with bordered={false}. #47372 @MadCcc
🐞 MISC: Fix that theme.inherit should not affect hashded and cssVar. #47360 @MadCcc
🐞 Fix Calendar panel not switch when change year or month. #47361
💄 Fix Table's sub-table style issue in virtual mode. #47333 @Enigama

🐞 修复 Steps type="inline" 时鼠标无法 hover 到正确的步骤上的问题。#47406
🐞 修复 DatePicker 与 TimePicker 弹出面板箭头没有考虑面板本身圆角的问题。#47389
🐞 修复 Dropdown menu.items 为空时依然显示的问题。#47375
🐞 修复 Tag 无边框模式没有正确使用 defaultBg 组件 token 的问题。#47372 @MadCcc
🐞 杂项：修复主题 inherit 配置会隔断 hashed 和 cssVar 配置的问题。#47360 @MadCcc
🐞 修复 Calendar 在切换年月时，面板没有跟着切换的问题。#47361
💄 修复 Table 在虚拟模式下子表格的样式问题。#47333 @Enigama

`v5.14.0`

Compare Source

🔥 Refactored the DatePicker component, details are follows. #46982
- 🆕 DatePicker adds multiple to support multiple selection capabilities.
- 🆕 DatePicker supports showWeek attribute.
- 🆕 DatePicker.RangePicker supports order attribute.
- 🆕 DatePicker id attribute under RangePicker supports setting the id of the start and end input boxes separately.
- 🆕 DatePicker onFocus and onBlur events of RangePicker will additionally provide an info.range to inform which input box the current focus comes from.
- 🆕 DatePicker add matching pickerValue and defaultPickerValue attributes to control the date where the expanded panel is located.
- 🆕 DatePicker add the preserveInvalidOnBlur attribute to keep the input content when losing focus in the case of accessibility.
- 🆕 DatePicker format supports the align attribute, allowing input content through the mask mode.
- 🆕 DatePicker Support required attribute.
- 🆕 DatePicker time panel supports scrollOnChange to automatically select the corresponding time when scrolling.
- 🆕 DatePicker add the needConfirm attribute to allow setting the confirmation or non-confirmation submission mode.
- 🆕 DatePicker add the components attribute to allow customizing some panels.
- 🆕 DatePicker all date-related information in the panel will allow configuration through locale.
- 🆕 DatePicker format supports LT and LTS date formats.
- 🆕 DatePicker add minDate and maxDate to set the panel switching range.
- 🐞 DatePicker defaultPickerValue will now be reset each time the panel is expanded.
- 🐞 DatePicker fix the problem that the input box function key will trigger the pop-up box, now it will only be triggered when the interactive key and the input content change.
- 🐞 DatePicker Losing focus after entering the date through the input box will submit the change instead of losing the input content (that is, it is no longer necessary to press Enter to submit).
- 🐞 DatePicker fix the problem that the hour obtained by disabledTime under use12Hours will also be clipped to 0~12.
- 🐞 DatePicker fix the problem that the disabled date is not effective and can still be submitted under some interactions.
- ⚡️ DatePicker Optimize disabledDate check logic, now it will provide info.type to inform the current panel information.
- 🛠 DatePicker allowClear trigger event from onMouseDown to onClick.
- 🛠 DatePicker Deprecate the preventDefault parameter of onKeyDown, please call it directly through event.preventDefault.
- 🛠 DatePicker Remove the keyboard interaction with the panel, it needs to be redesigned based on accessibility.
- 💄 DatePicker Remove the dotted line style of RangePicker to reduce visual interference.
- 💄 DatePicker Remove the disabled range of RangePicker when selecting start or end time to optimize the interaction experience.
🔥 Added support for stacked fixed columns in the Table component. #47245
🆕 Added support for components.body in the Table component under the virtual mode. #47098 by @linxianxi
🆕 Added support for generics in the Segmented value type. #47091 by @madocto
🆕 Added the changeOnWheel property to the InputNumber component to enable mouse wheel control. #47158 by @MadCcc
🆕 Added six tokens (defaultHoverBg, defaultHoverColor, defaultHoverBorderColor, defaultActiveBg, defaultActiveColor, and defaultActiveBorderColor) to the Button component. #47075 by @madocto
🆕 Added duration configuration support to the useNotification function in the Notification component. This update also applies to the notification configuration of the App component. #47141
🆕 Added support for configuring flex property in responsive layouts of the Grid component. #47124
🐞 Improved the Transfer internal padding of the Pagination component. #47231 by @qmhc
🐞 Fixed the alignment issue in the Avatar component when the height is less than 16px. #47236 by @lcgash
🐞 Fixed the incorrect mouse pointer when the Input component is disabled. #47280 by @MadCcc
🐞 Fixed the issue where the hoverBorderColor and activeBorderColor token customization didn't work in the Input component. #47243 by @MadCcc
💄 Fixed the issue where the hover style of submenus in the Menu component disappears at the edges. #47227 by @MadCcc
💄 Menu fixed component styling issues in non-hash mode. #46609 by @MadCcc
💄 Added classNames and styles properties to the Card component. #46811 by @zh-lx
ConfigProvider
- 🆕 Added support for selectionsIcon in the Transfer component to ConfigProvide. #47301 by @li-jia-nan
- 🆕 Added support for addIcon and moreIcon in the Tabs component to ConfigProvide. #47274 by @li-jia-nan
- 🆕 Added support for closeIcon in the Image component to ConfigProvide. #47252 by @li-jia-nan
- 🆕 Added support for closeIcon in the Tag component to ConfigProvide. #47250 by @li-jia-nan
- 🆕 Added support for closeIcon in the Notification component to ConfigProvide. #47244 by @li-jia-nan
- 🆕 Added support for closeIcon in the Modal component to ConfigProvide. #47226 by @li-jia-nan
- 🆕 Added support for expandIcon in the Table component to ConfigProvide. #47225 by @li-jia-nan
- 🆕 Added support for closeIcon in the Tour component to ConfigProvide. #47200 by @li-jia-nan
- 🆕 Added support for icons in the Drawer component to ConfigProvide. #46894 by @li-jia-nan
- 🆕 Added support for closeIcon in the Alert component to ConfigProvide. #47235 by @li-jia-nan

🔥 重构了 DatePicker 组件，详细改动如下。#46982
- 🆕 DatePicker 新增 multiple 支持多选能力。
- 🆕 DatePicker 支持 showWeek 属性。
- 🆕 DatePicker.RangePicker 下的 id 属性支持分别设置 start 和 end 输入框的 id。
- 🆕 DatePicker.RangePicker 的 onFocus 和 onBlur 事件会额外提供一个 info.range 告知当前的焦点来自于哪个输入框。
- 🆕 DatePicker.RangePicker 支持 order 属性。
- 🆕 DatePicker 新增配套 pickerValue、defaultPickerValue 属性用于受控管理展开面板所在日期。
- 🆕 DatePicker 新增 preserveInvalidOnBlur 属性用于无障碍时失去焦点需要保留输入内容的场景。
- 🆕 DatePicker format 支持 align 属性，允许通过掩码模式输入内容。
- 🆕 DatePicker 支持 required 属性。
- 🆕 DatePicker 时间面板支持 scrollOnChange 设置滚动时间时自动选择对应的时间。
- 🆕 DatePicker 添加 needConfirm 属性，允许设置需要确认、或者不确认的提交模式。
- 🆕 DatePicker 添加 components 属性，允许自定义部分面板。
- 🆕 DatePicker 面板中所有的日期相关信息都会允许通过 locale 进行配置。
- 🆕 DatePicker format 支持 LT、LTS 日期格式。
- 🆕 DatePicker 新增 minDate 和 maxDate 用于设置面板切换范围。
- 🐞 DatePicker 的defaultPickerValue 现在会在每次面板展开时都进行重置。
- 🐞 DatePicker 修复输入框功能按键会唤起弹出框的问题，现在只有在交互按键、以及输入内容变化时唤起。
- 🐞 DatePicker 通过输入框输入日期后失去焦点会提交变更，而不是丢失输入内容（即不再强制需要按下回车提交）。
- 🐞 DatePicker 修复 use12Hours 下，disabledTime 获取的 hour 也会被裁剪成 0~12 的问题。
- 🐞 DatePicker 修复某些交互下，禁用日期没有生效依然可以提交的问题。
- ⚡️ DatePicker 优化 disabledDate 检查逻辑，现在会提供 info.type 告知当前面板信息。
- 🛠 DatePicker 的 allowClear 触发事件从 onMouseDown 切换为 onClick。
- 🛠 移除 DatePicker 的键盘对面板交互，它需要基于无障碍重新设计。
- 🛠 DatePicker 废弃 onKeyDown 的 preventDefault 参数，请直接通过 event.preventDefault 进行调用。
- 💄 DatePicker.RangePicker 移除虚线样式，减少视觉干扰。
- 💄 DatePicker.RangePicker 移除在选择开始或者结束时间时的禁用范围，优化交互体验。
🔥 Table 支持堆叠固定列。#47245
🆕 Table 支持 virtual 下的 components.body。#47098 @linxianxi
🆕 Segmented value 类型支持泛型。#47091 @madocto
🆕 InputNumber 组件支持 changeOnWheel 属性，以启用鼠标滚轮控制。#47158 @MadCcc
🆕 Button 添加 defaultHoverBg、defaultHoverColor、defaultHoverBorderColor、 defaultActiveBg、defaultActiveColor 和 defaultActiveBorderColor 六个 token。#47075 @madocto
🆕 Notification useNotification 支持 duration 配置，该更新同样适用于 App 组件的 notification 配置。#47141
🆕 Grid 支持为响应式布局配置 flex 属性。#47124
🐞 改进 Transfer 组件分页器的内边距。#47231 @qmhc
🐞 修复 Avatar 组件当高度小于 16px 内容不居中的问题。#47236 @lcgash
🐞 修复 Input 组件禁用时鼠标指针不正确的问题。#47280 @MadCcc
🐞 修复 Input 组件 hoverBorderColor 和 activeBorderColor token 定制无效的问题。#47243 @MadCcc
💄 修复 Menu 组件子菜单 hover 样式在边缘消失的问题。#47227 @MadCcc
💄 修复 Menu 在无 hash 模式下的组件样式问题。#46609 @MadCcc
💄 Card 组件增加 classNames 和 styles 属性。#46811 @zh-lx
ConfigProvider
- 🆕 ConfigProvide 支持 Transfer 的 selectionsIcon。#47301 @li-jia-nan
- 🆕 ConfigProvide 支持 Tabs 的 addIcon 和 moreIcon。#47274 @li-jia-nan
- 🆕 ConfigProvide 支持 Image 的 closeIcon。#47252 @li-jia-nan
- 🆕 ConfigProvide 支持 Tag 的 closeIcon。#47250 @li-jia-nan
- 🆕 ConfigProvide 支持 Notification 的 closeIcon。#47244 @li-jia-nan
- 🆕 ConfigProvide 支持 Modal 的 closeIcon。#47226 @li-jia-nan
- 🆕 ConfigProvide 支持 Table 的 expandIcon。#47225 @li-jia-nan
- 🆕 ConfigProvide 支持 Tour 的 closeIcon。#47200 @li-jia-nan
- 🆕 ConfigProvide 支持 Drawer 的 icons。#46894 @li-jia-nan
- 🆕 ConfigProvide 支持 Alert 的 closeIcon。#47235 @li-jia-nan

cypress-io/cypress (cypress)

`v13.6.4`

Compare Source

Changelog: https://docs.cypress.io/guides/references/changelog#13-6-4

framer/motion (framer-motion)

`v11.0.5`

Compare Source

Updated

Performance updates.

`v11.0.4`

Compare Source

Fixed

Tighten check for navigator.userAgent.

garmeeh/next-seo (next-seo)

postcss/postcss (postcss)

`v8.4.35`

Compare Source

Avoid ! in node.parent.nodes type.
Allow to pass undefined to node adding method to simplify types.

`v8.4.34`

Compare Source

Fixed AtRule#nodes type (by Tim Weißenfels).
Cleaned up code (by Dmitry Kirillov).

csstools/postcss-plugins (postcss-preset-env)

`v9.4.0`

Compare Source

February 19, 2024

Added @csstools/postcss-light-dark-function Check the plugin README for usage details.
Fix type definitions
Remove extraneous dependency on postcss-value-parser
Updated @csstools/postcss-cascade-layers to 4.0.3 (patch)
Updated @csstools/postcss-color-function to 3.0.9 (patch)
Updated @csstools/postcss-color-mix-function to 2.0.9 (patch)
Updated @csstools/postcss-exponential-functions to 1.0.4 (patch)
Updated @csstools/postcss-font-format-keywords to 3.0.2 (patch)
Updated @csstools/postcss-gamut-mapping to 1.0.3 (patch)
Updated @csstools/postcss-gradients-interpolation-method to 4.0.10 (patch)
Updated @csstools/postcss-hwb-function to 3.0.9 (patch)
Updated @csstools/postcss-ic-unit to 3.0.4 (patch)
Updated @csstools/postcss-initial to 1.0.1 (patch)
Updated @csstools/postcss-is-pseudo-class to 4.0.5 (patch)
Updated @csstools/postcss-logical-float-and-clear to 2.0.1 (patch)
Updated @csstools/postcss-logical-overflow to 1.0.1 (patch)
Updated @csstools/postcss-logical-overscroll-behavior to 1.0.1 (patch)
Updated @csstools/postcss-logical-resize to 2.0.1 (patch)
Updated @csstools/postcss-logical-viewport-units to 2.0.6 (patch)
Updated @csstools/postcss-media-minmax to 1.1.3 (patch)
Updated @csstools/postcss-media-queries-aspect-ratio-number-values to 2.0.6 (patch)
Updated @csstools/postcss-nested-calc to 3.0.2 (patch)
Updated @csstools/postcss-normalize-display-values to 3.0.2 (patch)
Updated @csstools/postcss-oklab-function to 3.0.10 (patch)
Updated @csstools/postcss-progressive-custom-properties to 3.1.0 (minor)
Updated @csstools/postcss-relative-color-syntax to 2.0.10 (patch)
Updated @csstools/postcss-scope-pseudo-class to 3.0.1 (patch)
Updated @csstools/postcss-stepped-value-functions to 3.0.5 (patch)
Updated @csstools/postcss-text-decoration-shorthand to 3.0.4 (patch)
Updated @csstools/postcss-trigonometric-functions to 3.0.5 (patch)
Updated @csstools/postcss-unset-value to 3.0.1 (patch)
Updated css-blank-pseudo to 6.0.1 (patch)
Updated css-has-pseudo to 6.0.2 (patch)
Updated css-prefers-color-scheme to 9.0.1 (patch)
Updated cssdb to 7.11.0 (minor)
Updated postcss-attribute-case-insensitive to 6.0.3 (patch)
Updated postcss-color-functional-notation to 6.0.5 (patch)
Updated postcss-color-hex-alpha to 9.0.4 (patch)
Updated postcss-color-rebeccapurple to 9.0.3 (patch)
Updated postcss-custom-media to 10.0.3 (patch)
Updated postcss-custom-properties to 13.3.5 (patch)
Updated postcss-custom-selectors to 7.1.7 (patch)
Updated postcss-dir-pseudo-class to 8.0.1 (patch)
Updated postcss-double-position-gradients to 5.0.4 (patch)
Updated postcss-focus-visible to 9.0.1 (patch)
Updated postcss-focus-within to 8.0.1 (patch)
Updated postcss-gap-properties to 5.0.1 (patch)
Updated postcss-image-set-function to 6.0.3 (patch)
Updated postcss-lab-function to 6.0.10 (patch)
Updated postcss-logical to 7.0.1 (patch)
Updated postcss-nesting to 12.0.3 (patch)
Updated postcss-overflow-shorthand to 5.0.1 (patch)
Updated postcss-place to 9.0.1 (patch)
Updated postcss-pseudo-class-any-link to 9.0.1 (patch)
Updated postcss-selector-not to 7.0.2 (patch)

prettier/prettier (prettier)

`v3.2.5`

Compare Source

diff

Support Angular inline styles as single template literal (#15968 by @sosukesuzuki)

Angular v17 supports single string inline styles.

// Input
@&#8203;Component({
  template: `<div>...</div>`,
  styles: `h1 { color: blue; }`,
})
export class AppComponent {}

// Prettier 3.2.4
@&#8203;Component({
  template: `<div>...</div>`,
  styles: `h1 { color: blue; }`,
})
export class AppComponent {}

// Prettier 3.2.5
@&#8203;Component({
  template: `<div>...</div>`,
  styles: `
    h1 {
      color: blue;
    }
  `,
})
export class AppComponent {}

Unexpected embedded formatting for Angular template (#15969 by @JounQin)

Computed template should not be considered as Angular component template

// Input
const template = "foobar";

@&#8203;Component({
  [template]: `<h1>{{       hello }}</h1>`,
})
export class AppComponent {}

// Prettier 3.2.4
const template = "foobar";

@&#8203;Component({
  [template]: `<h1>{{ hello }}</h1>`,
})
export class AppComponent {}

// Prettier 3.2.5
const template = "foobar";

@&#8203;Component({
  [template]: `<h1>{{       hello }}</h1>`,
})
export class AppComponent {}

Use `"json"` parser for `tsconfig.json` by default (#16012 by @sosukesuzuki)

In v2.3.0, we introduced "jsonc" parser which adds trialing comma by default.

When adding a new parser we also define how it will be used based on the linguist-languages data.

tsconfig.json is a special file used by TypeScript, it uses .json file extension, but it actually uses the JSON with Comments syntax. However, we found that there are many third-party tools not recognize it correctly because of the confusing .json file extension.

We decide to treat it as a JSON file for now to avoid the extra configuration step.

To keep using the "jsonc" parser for your tsconfig.json files, add the following to your .pretterrc file

{
  "overrides": [
    {
      "files": ["tsconfig.json", "jsconfig.json"],
      "options": {
        "parser": "jsonc"
      }
    }
  ]
}

stylelint/stylelint (stylelint)

`v16.2.1`

Compare Source

Fixed: report flags not reporting on subsequent runs when cache is used (#7483) (@ybiquitous).
Fixed: custom-property-no-missing-var-function false positives for properties that can contain author-defined identifiers (#7478) (@ybiquitous).
Fixed: selector-pseudo-class-no-unknown false positives for :seeking, the media loading state and sound state pseudo-classes (#7490) (@Mouvedia).
Fixed: selector-max-specificity false positives with ignoreSelectors option for of <selector> syntax (#7475) (@ybiquitous).
Fixed: function-calc-no-unspaced-operator performance (#7505) (@ybiquitous).
Fixed: validateOptions to report when secondary option object is an empty object or null (#7476) (@ybiquitous).
Fixed: report() error message responsibility for a missing node or line number (#7474) (@ybiquitous).

yarnpkg/berry (yarn)

`v4.1.0`

Compare Source

Tweaks -,--verbose in yarn workspaces foreach; -v will now only print the prefixes, -vv will be necessary to also print the timings.
Adds a new --json option to yarn run when called without script name
Fixes node-modules linker link: depend

Configuration

📅 Schedule: Branch creation - "every weekend" in timezone Asia/Shanghai, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

vercel · 2024-02-02T20:26:35Z

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

Name	Status	Preview	Comments	Updated (UTC)
blog	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 20, 2024 5:21am

pull-request-quantifier-deprecated · 2024-02-02T20:26:38Z

This PR has 20 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +10 -10
Percentile : 8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +9 -9

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

github-actions · 2024-02-02T20:26:48Z

Lighthouse Report

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/

🚀 Vercel preview deployment
⚡ Lighthouse report

Category	Score
🟢 performance	95
🟢 accessibility	100
🟡 best-practices	78
🟢 seo	100
🟢 pwa	100

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/posts

🚀 Vercel preview deployment
⚡ Lighthouse report

Category	Score
🟢 performance	96
🟢 accessibility	94
🟡 best-practices	78
🟢 seo	100
🟢 pwa	100

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/tags

🚀 Vercel preview deployment
⚡ Lighthouse report

Category	Score
🟢 performance	99
🟢 accessibility	94
🟡 best-practices	78
🟢 seo	100
🟢 pwa	100

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/books

🚀 Vercel preview deployment
⚡ Lighthouse report

Category	Score
🟢 performance	100
🟢 accessibility	94
🟡 best-practices	78
🟢 seo	100
🟢 pwa	100

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/about

🚀 Vercel preview deployment
⚡ Lighthouse report

Category	Score
🟢 performance	99
🟢 accessibility	94
🟡 best-practices	78
🟢 seo	100
🟢 pwa	100

codecov · 2024-02-02T20:29:04Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1204   +/-   ##
=======================================
  Coverage   98.49%   98.49%           
=======================================
  Files         175      175           
  Lines         863      863           
  Branches       86       86           
=======================================
  Hits          850      850           
  Misses         10       10           
  Partials        3        3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

pull-request-quantifier-deprecated · 2024-02-02T22:05:17Z

This PR has 20 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +10 -10
Percentile : 8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +9 -9

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-03T04:59:03Z

This PR has 20 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +10 -10
Percentile : 8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +9 -9

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-03T16:43:50Z

This PR has 22 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +11 -11
Percentile : 8.8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +10 -10

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-04T07:27:32Z

This PR has 24 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +12 -12
Percentile : 9.6%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +11 -11

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-04T15:56:31Z

This PR has 24 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +12 -12
Percentile : 9.6%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +11 -11

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-05T04:34:03Z

This PR has 24 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +12 -12
Percentile : 9.6%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +11 -11

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

socket-security · 2024-02-05T13:26:57Z

Removed dependencies detected. Learn more about Socket for GitHub ↗︎

🚮 Removed packages: npm/[email protected]

View full report↗︎

pull-request-quantifier-deprecated · 2024-02-08T21:38:34Z

This PR has 30 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +15 -15
Percentile : 12%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +14 -14

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-12T15:40:40Z

This PR has 30 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +15 -15
Percentile : 12%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +14 -14

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-13T11:09:56Z

This PR has 30 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +15 -15
Percentile : 12%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +14 -14

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-13T17:06:53Z

This PR has 32 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +16 -16
Percentile : 12.8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +15 -15

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-15T12:12:19Z

This PR has 32 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +16 -16
Percentile : 12.8%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +15 -15

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-15T19:33:18Z

This PR has 36 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +18 -18
Percentile : 14.4%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +17 -17

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-17T08:15:23Z

This PR has 36 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +18 -18
Percentile : 14.4%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +17 -17

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-20T01:07:30Z

This PR has 38 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +19 -19
Percentile : 15.2%

Total files changed: 2

Change summary by file extension:
.yml : +1 -1
.json : +18 -18

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-02-20T05:19:32Z

This PR has 41 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +21 -20
Percentile : 16.4%

Total files changed: 3

Change summary by file extension:
.yml : +1 -1
.tsx : +2 -1
.json : +18 -18

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

renovate bot added the dependencies Pull requests that update a dependency file label Feb 2, 2024

pull-request-quantifier-deprecated bot added the Extra Small label Feb 2, 2024

vercel bot deployed to Preview February 2, 2024 20:29 View deployment

renovate bot assigned sabertazimi Feb 2, 2024

renovate bot requested a review from sabertazimi February 2, 2024 22:04

renovate bot force-pushed the renovate/dependencies branch from cd27b52 to 54e6a5f Compare February 2, 2024 22:05

vercel bot deployed to Preview February 2, 2024 22:08 View deployment

renovate bot force-pushed the renovate/dependencies branch from 54e6a5f to 6dfb4a5 Compare February 3, 2024 04:58

vercel bot deployed to Preview February 3, 2024 05:01 View deployment

renovate bot force-pushed the renovate/dependencies branch from 6dfb4a5 to 0966bdc Compare February 3, 2024 16:43

vercel bot deployed to Preview February 3, 2024 16:45 View deployment

renovate bot force-pushed the renovate/dependencies branch from 0966bdc to 3681299 Compare February 4, 2024 07:27

vercel bot deployed to Preview February 4, 2024 07:29 View deployment

renovate bot force-pushed the renovate/dependencies branch from 3681299 to 6e227e1 Compare February 4, 2024 15:56

vercel bot deployed to Preview February 4, 2024 15:59 View deployment

renovate bot force-pushed the renovate/dependencies branch from 6e227e1 to a7c1fc6 Compare February 5, 2024 04:33

vercel bot deployed to Preview February 5, 2024 04:35 View deployment

renovate bot force-pushed the renovate/dependencies branch from a7c1fc6 to 47a27a9 Compare February 5, 2024 13:25

vercel bot deployed to Preview February 5, 2024 13:28 View deployment

vercel bot deployed to Preview February 8, 2024 21:40 View deployment

renovate bot force-pushed the renovate/dependencies branch from a7e1c35 to 0bd34a3 Compare February 12, 2024 12:34

vercel bot deployed to Preview February 12, 2024 12:36 View deployment

renovate bot force-pushed the renovate/dependencies branch from 0bd34a3 to 6b6e2b8 Compare February 13, 2024 10:43

vercel bot deployed to Preview February 13, 2024 10:46 View deployment

renovate bot force-pushed the renovate/dependencies branch from 6b6e2b8 to f731bd1 Compare February 13, 2024 16:51

vercel bot deployed to Preview February 13, 2024 16:54 View deployment

renovate bot force-pushed the renovate/dependencies branch from f731bd1 to 4448fbb Compare February 15, 2024 12:12

vercel bot deployed to Preview February 15, 2024 12:14 View deployment

renovate bot force-pushed the renovate/dependencies branch from 4448fbb to b8defed Compare February 15, 2024 19:33

vercel bot deployed to Preview February 15, 2024 19:35 View deployment

renovate bot force-pushed the renovate/dependencies branch from b8defed to 6c46b8a Compare February 17, 2024 08:15

vercel bot deployed to Preview February 17, 2024 08:17 View deployment

fix(deps): update dependencies (non-major)

022c4d4

renovate bot force-pushed the renovate/dependencies branch from 6c46b8a to 022c4d4 Compare February 20, 2024 01:07

vercel bot deployed to Preview February 20, 2024 01:10 View deployment

sabertazimi approved these changes Feb 20, 2024

View reviewed changes

style: format code

d2a3244

vercel bot deployed to Preview February 20, 2024 05:21 View deployment

sabertazimi merged commit 37c2fd1 into main Feb 20, 2024
12 checks passed

sabertazimi deleted the renovate/dependencies branch February 20, 2024 05:24

fix(deps): update dependencies (non-major) #1204

fix(deps): update dependencies (non-major) #1204

Conversation

renovate bot commented Feb 2, 2024 • edited Loading

Release Notes

Bug Fixes

Features

Features

2.11.3 (2024-01-17)

Bug Fixes

2.11.2 (2024-01-11)

Bug Fixes

2.11.1 (2024-01-10)

Bug Fixes

Features

Bug Fixes

Bug Fixes

Features

Bug Fixes

Features

Updated

Fixed

What's Changed

New Contributors

Support Angular inline styles as single template literal (#​15968 by @​sosukesuzuki)

Unexpected embedded formatting for Angular template (#​15969 by @​JounQin)

Use "json" parser for tsconfig.json by default (#​16012 by @​sosukesuzuki)

Configuration

vercel bot commented Feb 2, 2024 • edited Loading

pull-request-quantifier-deprecated bot commented Feb 2, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

github-actions bot commented Feb 2, 2024 • edited Loading

Lighthouse Report

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/posts

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/tags

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/books

✨ https://blog-1sag8q1dr-sabertaz.vercel.app/about

codecov bot commented Feb 2, 2024 • edited Loading

Codecov Report

pull-request-quantifier-deprecated bot commented Feb 2, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 3, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 3, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 4, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 5, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

socket-security bot commented Feb 5, 2024 • edited Loading

pull-request-quantifier-deprecated bot commented Feb 8, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 12, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 15, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 15, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 17, 2024

What can I do to optimize my changes

renovate bot commented Feb 2, 2024 •

edited

Loading

Support Angular inline styles as single template literal (#15968 by @sosukesuzuki)

Unexpected embedded formatting for Angular template (#15969 by @JounQin)

Use `"json"` parser for `tsconfig.json` by default (#16012 by @sosukesuzuki)

vercel bot commented Feb 2, 2024 •

edited

Loading

github-actions bot commented Feb 2, 2024 •

edited

Loading

codecov bot commented Feb 2, 2024 •

edited

Loading

socket-security bot commented Feb 5, 2024 •

edited

Loading