You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Only selected Actions are allowed within this repository. Please refer to (https://github.com/nodejs/nodejs.org/settings/actions)
3
3
# for the full list of available actions. If you want to add a new one, please reach out a maintainer with Admin permissions.
4
-
# REVIEWERS, please always double-check security practices before merging a PR that contains Workflow changes!!
4
+
# REVIEWERS, please always double-check security practices before merging a PR that contains workflow changes!!
5
5
# AUTHORS, please only use actions with explicit SHA references, and avoid using `@master` or `@main` references or `@version` tags.
6
6
7
7
name: Linting and Tests
8
8
9
+
# This workflow should run either on `merge_group`, `pull_request`, or `push` events
10
+
# since we want to run lint checks against any changes on pull requests, or the final patch on merge groups
11
+
# or if direct pushes happen to main (or when changes in general land on the `main` (default) branch)
12
+
# Note that the reason why we run this on pushes against `main` is that on rare cases, maintainers might do direct pushes against `main`
13
+
9
14
on:
10
15
push:
11
16
branches:
12
17
- main
13
-
pull_request_target:
18
+
pull_request:
14
19
branches:
15
20
- main
16
-
types:
17
-
- labeled
18
21
merge_group:
19
22
20
-
defaults:
21
-
run:
22
-
# This ensures that the working directory is the root of the repository
23
-
working-directory: ./
24
-
23
+
# The permissions specified below apply to workflows triggered by `merge_group`, `push`, and `pull_request` events that originate from the same repository (non-fork).
24
+
# However, workflows triggered by `pull_request` events from forked repositories are treated differently for security reasons:
25
+
# - These workflows **do not** have access to any secrets configured in the repository.
26
+
# - They are also **not granted any permissions** to perform actions on the base repository.
27
+
#
28
+
# This is a deliberate security restriction designed to prevent potential abuse through malicious pull requests from forks.
29
+
# For a deeper explanation and best practices for securing your GitHub Actions workflows, particularly against so-called "pwn requests",
30
+
# refer to https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
25
31
permissions:
26
32
contents: read
27
33
actions: read
28
-
# This permission is required by `MishaKav/jest-coverage-comment`
29
-
pull-requests: write
30
34
31
35
env:
32
36
# See https://turbo.build/repo/docs/reference/command-line-reference/run#--force
33
37
TURBO_FORCE: true
34
38
35
39
jobs:
36
40
lint:
37
-
# This Job should run either on `merge_groups` or `push` events
38
-
# or `pull_request_target` event with a `labeled` action with a label named `github_actions:pull-request`
39
-
# since we want to run lint checks against any changes on pull requests, or the final patch on merge groups
40
-
# or if direct pushes happen to main (or when changes in general land on the `main` (default) branch)
41
-
# Note that the reason why we run this on pushes against `main` is that on rare cases, maintainers might do direct pushes against `main`
Copy file name to clipboardExpand all lines: COLLABORATOR_GUIDE.md
+2-4Lines changed: 2 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -418,7 +418,7 @@ You can add a PACKAGE_MANAGER the same way as adding an INSTALLATION_METHOD (fro
418
418
## Unit Tests and Storybooks
419
419
420
420
Each new feature or bug fix should be accompanied by a unit test (when deemed valuable).
421
-
We use [Jest][] as our test runner and [React Testing Library][] for our React unit tests.
421
+
We use [`node:test`][] as our test runner and [React Testing Library][] for our React unit tests.
422
422
423
423
We also use [Storybook][] to document our components.
424
424
Components within `packages/ui-components` should have a storybook story that documents the component's usage.
@@ -434,8 +434,6 @@ Unit Tests are fundamental to ensure that code changes do not disrupt the functi
434
434
- Unit Tests should ensure that a given change's functionality is working as expected.
435
435
- When creating unit tests for React components, we recommend that the tests cover all the possible states of the component.
436
436
- We also recommend mocking external dependencies, if unsure about how to mock a particular dependency, raise the question on your Pull Request.
437
-
- We recommend using [Jest's Mock Functions](https://jestjs.io/docs/en/mock-functions) for mocking dependencies.
438
-
- We recommend using [Jest's Mock Modules](https://jestjs.io/docs/en/manual-mocks) for mocking dependencies unavailable on the Node.js runtime.
439
437
- Common Providers and Contexts from the lifecycle of our App, such as [`next-intl`][] should not be mocked but given an empty or fake context whenever possible.
440
438
- We recommend reading previous unit tests from the codebase for inspiration and code guidelines.
441
439
@@ -643,7 +641,7 @@ A lot of the current structure is due to retro-compatibility, keeping a simple a
643
641
644
642
If you're unfamiliar or curious about something, we recommend opening a Discussion on this GitHub Repository.
Copy file name to clipboardExpand all lines: DEPENDENCY_PINNING.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,14 +12,14 @@ The following recommendations are in order when adding a new dependency:
12
12
- Some non-code dependencies are required for the bootstrap of the repository. They are either used on basic build scripts or Git Hooks. Examples include `husky`, `lint-staged` and others.
13
13
- A dependency should be a `devDependencies` if it is not invoked anywhere within the codebase.
14
14
- This applies to runtimes, tooling, utility/dev-only commands, type packages and others
15
-
- Sometimes, a dependency should be a `devDependency` even if invoked within the codebase, but only used within a development environment or during a test runner. Examples include `jest`, `storybook` and others.
15
+
- Sometimes, a dependency should be a `devDependency` even if invoked within the codebase, but only used within a development environment or during a test runner. Examples include `storybook` and others.
16
16
- A dependency should be a `peerDependencies` if it is a runtime dependency of the Website, but the Website itself does not install it. Examples include `react`, `react-dom` and others.
17
17
18
18
### When pinning dependencies
19
19
20
20
When adding dependencies, you should consider if that dependency should be saved as an exact dependency (`--save-exact`) or use either a `^` or `~` version range operator. The following guidelines are in order:
21
21
22
-
- A dependency, in general, should be pinned to its exact dependency if it's either a tooling or a CLI dependency. Examples include `husky`, `prettier`, `jest`and others.
22
+
- A dependency, in general, should be pinned to its exact dependency if it's either a tooling or a CLI dependency. Examples include `husky`, `prettier`, and others.
23
23
- A dependency should generally use `~` if we're interested in patch updates (such as hot-fixes and bug-fixes) and the package is part of the Development or Testing Environment. (Such as `storybook`, for example)
24
24
- A dependency should generally use `^` if they're part of the Website Application itself, such as `react`, `next-intl` etc. This is done because we intentionally want to get these dependencies' latest features and bug-fixes.
25
25
- If we're not interested in getting the latest features and bug fixes, we should consider using `~` instead.
0 commit comments