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
Copy file name to clipboardExpand all lines: COLLABORATOR_GUIDE.md
+2-4
Original file line number
Diff line number
Diff line change
@@ -419,7 +419,7 @@ You can add a PACKAGE_MANAGER the same way as adding an INSTALLATION_METHOD (fro
419
419
## Unit Tests and Storybooks
420
420
421
421
Each new feature or bug fix should be accompanied by a unit test (when deemed valuable).
422
-
We use [Jest][] as our test runner and [React Testing Library][] for our React unit tests.
422
+
We use [`node:test`][] as our test runner and [React Testing Library][] for our React unit tests.
423
423
424
424
We also use [Storybook][] to document our components.
425
425
Components within `packages/ui-components` should have a storybook story that documents the component's usage.
@@ -435,8 +435,6 @@ Unit Tests are fundamental to ensure that code changes do not disrupt the functi
435
435
- Unit Tests should ensure that a given change's functionality is working as expected.
436
436
- When creating unit tests for React components, we recommend that the tests cover all the possible states of the component.
437
437
- We also recommend mocking external dependencies, if unsure about how to mock a particular dependency, raise the question on your Pull Request.
438
-
- We recommend using [Jest's Mock Functions](https://jestjs.io/docs/en/mock-functions) for mocking dependencies.
439
-
- We recommend using [Jest's Mock Modules](https://jestjs.io/docs/en/manual-mocks) for mocking dependencies unavailable on the Node.js runtime.
440
438
- 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.
441
439
- We recommend reading previous unit tests from the codebase for inspiration and code guidelines.
442
440
@@ -644,7 +642,7 @@ A lot of the current structure is due to retro-compatibility, keeping a simple a
644
642
645
643
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-2
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