Skip to content

Commit 228f6b6

Browse files
angeloashmoreangeloashmore
authoredJun 10, 2024··
docs: update CONTRIBUTING.md (#340)
* docs: new CONTRIBUTING.md * chore: new PR template * docs: fix errors * docs: add Prismic employee section * docs: add foonotes * docs: remove duplicate content * docs: fix typo * docs: fix typo * chore: remove `PULL_REQUEST_TEMPLATE` in favor of the org-level version
·
v7.16.1v7.6.0
1 parent a653884 commit 228f6b6

File tree

2 files changed

+89
-427
lines changed

2 files changed

+89
-427
lines changed
 

‎.github/PULL_REQUEST_TEMPLATE.md

-27
This file was deleted.

‎CONTRIBUTING.md

+89-400
Original file line numberDiff line numberDiff line change
@@ -1,448 +1,137 @@
1-
# Contributing to Prismic
1+
# Contributing
22

3-
This document is aimed at providing developers (mainly maintainers) documentation on this project and its structure. It is not intended to pass requirements for contributing to this project.
3+
This package is primarily maintained by [Prismic](https://prismic.io)[^1]. External contributions are welcome. Ask for help by [opening an issue](https://github.com/prismicio/prismic-client/issues/new/choose), or request a review by opening a pull request.
44

5-
For the latter, the [Quick Start](#quick-start) section below can help you. You are free to [open issues][repo-issue] and [submit pull requests][repo-pull-requests] toward the `master` branch directly without worrying about our standards. For pull requests, we will help you through our merging process.
5+
## :gear: Setup
66

7-
> For a Table of Contents, use GitHub's TOC button, top left of the document.
7+
<!-- When applicable, list system requriements to work on the project. -->
88

9-
## Quick Start
9+
The following setup is required to work on this project:
1010

11-
```bash
12-
# First, fork the repository to your GitHub account if you aren't an existing maintainer
11+
- Node.js
12+
- npm CLI
1313

14-
# Clone your fork
15-
git clone git@github.com:<your-username>/prismic-client.git
14+
## :memo: Project-specific notes
1615

17-
# Create a feature branch with your initials and feature name
18-
git checkout -b <your-initials>/<feature-or-fix-description> # e.g. `lh/fix-win32-paths`
16+
<!-- Share information about the repository. -->
17+
<!-- What specific knowledge do contributors need? -->
1918

20-
# Install dependencies with npm
21-
npm install
19+
> [!TIP]
20+
> Please update this section with helpful notes for contributors.
2221
23-
# Test your changes
24-
npm run test
22+
#### Public types
2523

26-
# Commit your changes once they are ready
27-
# Conventional Commits are encouraged, but not required
28-
git add .
29-
git commit -m "short description of your changes"
24+
`@prismicio/client` exports public-facing types for Prismic models and REST API V2 responses. They will likely need to be modified when models are changed.
3025

31-
# Lastly, open a pull request on GitHub describing your changes
32-
```
26+
- Model types are written in `src/types/model`. Each field type (e.g. key text) or composite field type (e.g. shared slice) has its own file.
27+
- REST API V2 types are written in `src/types/value`. Each field type (e.g. key text) or composite field type (e.g. shared slice) has its own file.
28+
- Repository API values, like `/api/v2` and ref values, are written in `src/types/api`. These files generally do not need to be edited for model changes.
29+
- Webhook API values are written in `src/types/webhook`. These files generally do not need to be edited for model changes.
3330

34-
## Processes
31+
#### Content helpers
3532

36-
Processes refer to tasks that you may need to perform while working on this project.
33+
- `@prismicio/client` provides helpers for manipulating Prismic content. For example, `asDate` converts a date field to a JavaScript `Date` instance.
34+
- Helpers are located in `src/helpers` with one file per helper. Find helpers that are affected by your model changes and update them accordingly.
35+
- If your model changes require a new helper, add it to the library. In general, wait for usage patterns to emerge from users before adding helpers. You don’t want to write helpers that no one will use.
3736

38-
### Developing
37+
#### Tests
3938

40-
There is no development branch. The `master` branch refers to the latest [stable (living) version](#stable-xxx) of the project and pull requests should be made against it.
39+
`@prismicio/client` has tests for its JavaScript/TypeScript API. It also has tests for its public TypeScript types.
4140

42-
If development on a [new major version](#iteration-cycle) has begun, a branch named after the major version will be created (e.g. `v2` for work on the future `v2.0.0` of the project). Pull requests targeting that new major version should be made against it.
41+
##### JavaScript/TypeScript tests
4342

44-
To develop locally:
43+
- Any change to this library should be tested. A test can be as simple as ensuring a helper has the correct output.
44+
- Tests should be placed in the `test` directory using the existing file name convention.
45+
- Tests are written using Vitest.
4546

46-
1. **If you have maintainer access**:<br/>[Clone the repository](https://help.github.com/articles/cloning-a-repository) to your local environment.
47+
##### TypeScript type tests
4748

48-
**If you do no have maintainer access**:<br/>[Fork](https://help.github.com/articles/fork-a-repo) and [clone](https://help.github.com/articles/cloning-a-repository) the repository to your local environment.
49+
- Any change to this library should be tested. A test can be as simple as ensuring a type is compatible with a payload.
50+
- Type tests should be placed in the `test/types` directory using the existing file name convention.
51+
- Tests are written using `ts-expect` and run using `tsc`.
4952

50-
2. Create a new branch:
51-
52-
```bash
53-
git checkout -b <your-initials>/<feature-or-fix-description> # e.g. `aa/graphql-support`
54-
```
53+
## :construction_worker: Develop
5554

56-
3. Install dependencies with [npm][npm] (avoid using [Yarn][yarn]):
55+
> [!NOTE]
56+
> It's highly recommended to discuss your changes with the Prismic team before starting by [opening an issue](https://github.com/prismicio/prismic-client/issues/new/choose).[^2]
57+
>
58+
> A short discussion can accellerate your work and ship it faster.
5759
58-
```bash
60+
```sh
61+
# Clone and prepare the project.
62+
git clone git@github.com:prismicio/prismic-client.git
63+
cd prismic-client
5964
npm install
60-
```
6165

62-
4. Start developing:
66+
# Create a new branch for your changes (e.g. lh/fix-win32-paths).
67+
git checkout -b <your-initials>/<feature-or-fix-description>
6368

64-
```bash
69+
# Start the development watcher.
70+
# Run this command while you are working on your changes.
6571
npm run dev
66-
```
67-
68-
5. Commit your changes:
69-
70-
If you already know the [Conventional Commits convention][conventional-commits], feel free to embrace it for your commit messages. If you don't, no worries; it can always be taken care of when the pull request is merged.
7172

72-
### Building
73-
74-
Our build system is handled by [Vite][vite]. Vite takes care of:
75-
76-
- Generating a [CommonJS (`.cjs`)](https://nodejs.org/docs/latest/api/modules.html#modules_modules_commonjs_modules) bundle and its source map;
77-
- Generating an [ECMAScript (`.mjs`)](https://nodejs.org/docs/latest/api/modules.html#modules_modules_commonjs_modules) bundle and its source map;
78-
- Generating a TypeScript declaration (`.d.ts`) file.
79-
80-
To build the project:
81-
82-
```bash
73+
# Build the project for production.
74+
# Run this command when you want to see the production version.
8375
npm run build
84-
```
85-
86-
The CI system will try to build the project on each commit targeting the `master` branch. The CI check will fail if the build does.
87-
88-
### Testing
89-
90-
All projects have at least linting and unit tests. Linting is handled by [ESLint][eslint] with [Prettier][prettier] and unit tests are handled by [Vitest][vitest].
91-
92-
To run all tests:
93-
94-
```bash
95-
npm run test
96-
```
97-
98-
If you'd like to run only the linter (note that it won't reformat your code; use the `format` script for that):
9976

100-
```bash
77+
# Lint your changes before requesting a review. No errors are allowed.
10178
npm run lint
102-
```
79+
# Some errors can be fixed automatically:
80+
npm run lint -- --fix
10381

104-
If you'd like to run only the unit tests:
82+
# Format your changes before requesting a review. No errors are allowed.
83+
npm run format
10584

106-
```bash
85+
# Test your changes before requesting a review.
86+
# All changes should be tested. No failing tests are allowed.
87+
npm run test
88+
# Run only unit tests (optionally in watch mode):
10789
npm run unit
90+
npm run unit:watch
91+
# Run only type tests
92+
npm run types
10893
```
10994

110-
If you'd like to run only the unit tests in watch mode (re-runs tests each time a file is saved):
111-
112-
```bash
113-
npm run unit -- --watch
114-
```
115-
116-
When working on unit tests, you might want to update snapshots (be careful when doing so):
117-
118-
```bash
119-
npm run unit -- --update-snapshots
120-
```
95+
## :building_construction: Submit a pull request
12196

122-
The CI system will run tests on each commit targeting the `master` branch. The CI check will fail if any test does.
97+
> [!NOTE]
98+
> Code will be reviewed by the Prismic team before merging.[^3]
99+
>
100+
> Request a review by opening a pull request.
123101
124-
### Publishing
102+
```sh
103+
# Open a pull request. This example uses the GitHub CLI.
104+
gh pr create
125105

126-
> ⚠ &nbsp;Only project maintainers with at least collaborator access to the related npm package can publish new versions.
106+
# Someone from the Prismic team will review your work. This review will at
107+
# least consider the PR's general direction, code style, and test coverage.
127108

128-
Publishing a package correctly involves multiple steps:
109+
# When ready, PRs should be merged using the "Squash and merge" option.
110+
```
129111

130-
- Writing a changelog;
131-
- [Building](#building) the project;
132-
- Publishing a new version tag to GitHub;
133-
- Publishing build artifacts to [npm][npm].
112+
## :rocket: Publish
134113

135-
In order to make sure all these steps are consistently and correctly done, we use [Standard Version][standard-version] and build scripts.
114+
> [!CAUTION]
115+
> Publishing is restricted to the Prismic team.[^4]
136116
137-
To release a new version of the project:
117+
```sh
118+
# Checkout the master branch and pull the latest changes.
119+
git checkout master
120+
git pull
138121

139-
```bash
122+
# Perform a dry-run and verify the output.
123+
# If it looks good, release a new version.
124+
npm run release:dry
140125
npm run release
141-
```
142126

143-
To release a new [alpha](#alpha-xxx-alphax) version of the project:
144-
145-
```bash
127+
# Or release an alpha.
128+
# Perform a dry-run and verify the output.
129+
# If it looks good, release a new alpha version.
130+
npm run release:alpha:dry
146131
npm run release:alpha
147132
```
148133

149-
Those scripts will:
150-
151-
- Run tests and try to build the project;
152-
- Figure out the new version number by looking at commit messages matching the [Conventional Commits convention][conventional-commits];
153-
- Write the [changelog][changelog] for the new version after Conventional Commit messages;
154-
- Build the project for publishing;
155-
- Publish a new version tag to GitHub;
156-
- Publish build artifacts to [npm][npm].
157-
158-
Once a script has been run successfully, a new version of the package should have been published to npm. To complete the publishing process you only need to head to the repository's releases tab on GitHub to publish the new version tag that was created.
159-
160-
If you ran any of those commands but happen not to have access to the related npm package, you can still ask a collaborator of the said package to publish it for you.
161-
162-
Appending `:dry` (e.g. `release:dry`) to any of the above commands will dry-run the targeted release script and output the new changelog to the console.
163-
164-
We consider maintaining project dependencies before publishing a new version a best practice.
165-
166-
### Maintaining
167-
168-
Anyone can, and is welcome to, contribute to the project by opening bug reports and submitting feature requests. To remain focused and ensure we are able to respond to each contribution, we have adopted the following framework to maintain this package:
169-
170-
**🚨 &nbsp;Bug reports**
171-
172-
> **Note**: An automated reply is posted when a bug report is opened to explain our maintenance schedule.
173-
174-
Every Wednesday is _bug squashing day_. During this day, we respond to and/or fix bug reports.
175-
176-
At the end of each Wednesday (assuming there were issues to fix), or later during the week if reviews are required, a _patch_ version is [released](#publishing) containing any fixes that were needed. Releasing multiple patches during the same week should be avoided.
177-
178-
Ideally, all opened bug reports are addressed each Wednesday. If a particular bug report is not able to be resolved in that timeframe, maintainers are free to continue working on the issue or to report back to it next Wednesday. Overall, while most issues should be closed within _7 days_, we consider up to _14 days_ to get back to and address an issue a reasonable delay. Beyond that threshold, an issue is considered problematic and will be given more attention.
179-
180-
**🙋‍♀️ &nbsp;Feature requests**
181-
182-
> **Note**: An automated message gets sent to people creating feature requests about this process.
183-
184-
Every last week of a month is _feature week_. During this week, we implement new features. Discussing and coming up with implementation proposals can happen before that week, but implementations are targeted for the last week.
185-
186-
At the end of the week (assuming there were features to implement), a _minor_ version is [released](#publishing) containing the new features. Releasing multiple minors during the same week should be avoided.
187-
188-
Ideally, all opened feature requests are discussed each month and implemented if consensus was reached. Unlike bug reports, we do not consider delays to address feature requests as good or bad. Instead, those should essentially be driven by the community's demand on a per-request basis.
189-
190-
**🏗 &nbsp;Updating the project structure**
191-
192-
We actively maintain a [TypeScript template][template] with Prismic's latest open-source standards. Keeping every project in sync with this template is nearly impossible so we're not trying to immediately reflect changes to the template in every project. Instead we consider a best practice to manually pull changes from the template into the project whenever someone is doing project maintenance and has time for it, or wants to enjoy the latest standards from it.
193-
194-
## `@prismicio/client` in Prismic's Open-Source Ecosystem
195-
196-
Prismic's Open-Source ecosystem is built around a 3-stage pyramid:
197-
198-
<p align="center">
199-
<img src="./.github/prismic-oss-ecosystem.svg" alt="Prismic open-source pyramid" height="384" />
200-
</p>
201-
202-
Where:
203-
204-
- **Core**: Represents libraries providing core Prismic integration such as data fetching and content transformation, e.g. [`@prismicio/client`](https://github.com/prismicio/prismic-client);
205-
- **Integration**: Represents libraries to integration into UI libraries. They must be framework agnostic, e.g. [`@prismicio/react`](https://github.com/prismicio/prismic-react);
206-
- **Framework**: Represents libraries to integrate into frameworks, including data fetching and normalizing. They must follow frameworks' expected practices, e.g. [`@prismicio/next`](https://github.com/prismicio/prismic-next).
207-
208-
<!-- TODO: Uncomment and complete correct one -->
209-
210-
<!-- This package is a **Core** library. -->
211-
<!-- This package is an **Integration** library, it relies on [XXX](#) and [YYY](#) **Core** libraries. -->
212-
<!-- This package is a **Framework** library, it relies on [XXX](#) **Integration** library. -->
213-
214-
## Iteration Cycle
215-
216-
We break iteration cycle of a project's library into 4 phases:
217-
218-
- **Pre-alpha**
219-
- **Alpha**
220-
- **Beta**
221-
- **Stable**
222-
223-
### Pre-alpha
224-
225-
> At any point we might feel the need to introduce breaking changes to a project's library (getting rid of legacy APIs, embracing latest features from a framework, etc.). When such a need has been identified for a project, it will enter the pre-alpha phase. The project might also enter the pre-alpha phase for large, non-breaking changes that need more planning and thoughts.
226-
>
227-
> The goal of the pre-alpha phase is to design and share the new project's library API through an RFC. Under certain circumstances (e.g. the API has already been clearly defined in another language and only some adaptations have to be made), the project can skip the pre-alpha phase and enter the alpha phase directly. Skipping the pre-alpha phase should be treated as an exception.
228-
229-
During the pre-alpha phase, the following will happen:
230-
231-
**Documenting and understanding the library's current functionality:**
232-
233-
Doing so leads to a better understanding of the library's current functionality and limitations. Reviewing GitHub Issues will provide insight into existing bugs and user requests. We want to reduce the number of breaking changes where possible while not being afraid to do so if necessary.
234-
235-
**Sketching the API in code, examples, and written explanations:**
236-
237-
The library should be written in concept before its concrete implementation. This frees us from technical limitations and implementation details. It also allows us to craft the best feeling API.
238-
239-
**Writing the public RFC:**
240-
241-
A formal RFC should be posted publicly once the initial brainstorming session is complete that focuses on new and changed concepts. This allows everyone to read and voice their opinions should they choose to.
242-
243-
### Alpha (`x.x.x-alpha.x`)
244-
245-
> As soon as the RFC has been posted, the project enters the alpha phase.
246-
>
247-
> The goal of the alpha phase is to implement the new project's library API, to test it, and to document it.
248-
249-
During the alpha phase, the following will happen:
250-
251-
**Writing the implementation:**
252-
253-
The implementation must be done in TypeScript and include extensive tests and in-code documentation. Generally the process goes as follows:
254-
255-
1. Writing the implementation in TypeScript;
256-
2. Testing the implementation;
257-
3. Documenting the implementation with TSDocs (at least all publicly exported APIs).
258-
259-
**Publishing public alpha versions:**
260-
261-
Publishing alpha versions of the library allows for easier internal testing. With alpha versions, users can test the library as it is published publicly, however those versions are not recommended or shared extensively as breaking changes are still very likely to occur and the library is still not documented. Alpha versions can be published as often as needed.
262-
263-
**Adjusting per internal and external feedback:**
264-
265-
An internal code review should be performed. As users use the alpha, issues will be opened for bugs and suggestions. Appropriate adjustments to the library should be made with a focus on doing what users expect while minimizing technical debt. For that purpose, breaking changes to the new API can be introduced.
266-
267-
**Updating documentation:**
268-
269-
Documentation for the library should be updated on [prismic.io][prismic-docs] and is treated as the primary source of documentation. Contributors will work closely with Prismic Education team to complete this. This involves updating related documentation and code examples as well, including any starter projects on GitHub. A migration guide should be included if necessary.
270-
271-
### Beta (`x.x.x-beta.x`)
272-
273-
> As soon as the implementation is completed and the updated documentation is ready to be published, the project enters the beta phase.
274-
>
275-
> The goal of the beta phase is to test the updated library's API by publicly sharing it with the community and receiving early adopters' feedback. The beta phase is the last opportunity for breaking changes to be introduced.
276-
277-
During the beta phase, the following will happen:
278-
279-
**Publishing public beta versions and related documentation:**
280-
281-
A first beta should be published along the related documentation that has been worked on during the alpha phase. This release should be announced and shared to users in order to get feedback from early adopters. Subsequent beta versions can be published as often as needed, but we have to keep in mind users are now expected to be using them.
282-
283-
**Adjusting per internal and external feedback:**
284-
285-
As users use the beta, issues will be opened for bugs and suggestions. Appropriate adjustments to the library should be made with a focus on doing what users expect while minimizing technical debt. For that purpose, breaking changes to the new API can still be introduced and documentation should be updated accordingly at the moment of publishing a new beta.
286-
287-
### Stable (`x.x.x`)
288-
289-
> Once the beta phase has arrived to maturity (users seem to be happy with it, all issues and concerns have been addressed, etc.), the project enters the stable phase.
290-
>
291-
> The goal of the stable phase is to publish the new project version and to advocate it as Prismic's latest standard. During this "living" phase of the project bug fixes and new features will be added. If the need for breaking or large changes arises, the project will enter the pre-alpha phase and begin a new cycle.
292-
293-
During the stable phase, the following will happen:
294-
295-
**Publishing public stable versions and related documentation:**
296-
297-
The first stable version should be published along the related documentation. This release should be announced and shared to users extensively in order to get them up to Prismic latest standard. Subsequent stable versions can be published as often as needed but a particular attention should be paid toward testing and avoiding regressions.
298-
299-
**Implementing new features:**
300-
301-
New features can be implemented during the stable phase following user suggestions and new use cases discovered. To be published, new features should be extensively tested. Ideally, documentation should be updated at the time of publishing, however a delay is tolerated here as it requires coordination with the Prismic Education team.
302-
303-
**Adding new examples:**
304-
305-
While examples can be added at any time, it's certainly during the stable phase that most of them will be added. Examples should be added whenever it feels relevant for a use case to be pictured with a recommended recipe, allowing for later shares of said examples.
306-
307-
## Project Structure
308-
309-
> Prismic open-source projects have been structured around standards maintainers brought from their different background and agreed upon on. They are meant to implement the same sensible defaults allowing for a coherent open-source ecosystem.
310-
>
311-
> Any changes to this structure are welcome but they should be first discussed on our [TypeScript template][template-issue]. Common sense still applies on a per-project basis if one requires some specific changes.
312-
313-
Project is structured as follows (alphabetically, folders first):
314-
315-
### 📁 &nbsp;`.github`
316-
317-
This folder is used to configure the project's GitHub repository. It contains:
318-
319-
**Issue templates (`ISSUE_TEMPLATE/*`)**
320-
321-
Those are used to standardize the way issues are created on the repository and to help with their triage by making sure all needed information is provided. Issue templates are also used to redirect users to our [community forum][community-forum] when relevant.
322-
323-
**Pull request templates (`PULL_REQUEST_TEMPLATE.md`)**
324-
325-
This one is used to standardize the way pull requests are created on the repository and to help with their triage by making sure all needed information is provided.
326-
327-
**CI configuration (`.github/workflows/ci.yml`)**
328-
329-
Our CI workflow is configured to run against all commits and pull requests directed toward the `master` branch. It makes sure the project builds and passes all tests configured on it (lint, unit, e2e, etc.) Coverage and bundle size are also collected by this workflow.
330-
331-
### 📁 &nbsp;`dist`
332-
333-
This folder is not versioned. It contains the built artifacts of the project after a successful build.
334-
335-
### 📁 &nbsp;`examples`
336-
337-
This folder contains examples of how to use the project. Examples are meant to be written over time as new use cases are discovered.
338-
339-
### 📁 &nbsp;`playground`
340-
341-
This folder might not be available in this project. If it is, it is meant to contain a playground for developers to try the project during the development process.
342-
343-
Scripts such as `playground:dev` or `playground:build` might be available inside the project [package.json](#-packagejson) to interact with it easily.
344-
345-
### 📁 &nbsp;`src`
346-
347-
This folder contains the source code of the project written in TypeScript. The `index.ts` file inside it should only contain exports made available by the project. It should not contain any logic.
348-
349-
### 📁 &nbsp;`test`
350-
351-
This folder contains tests of the project written in TypeScript. It may contain the following subdirectory:
352-
353-
**Fixtures (`__fixtures__`)**
354-
355-
This folder contains [fixtures](https://en.wikipedia.org/wiki/Test_fixture) used to test the project.
356-
357-
**Test Utils (`__testutils__`)**
358-
359-
This folder contains utility functions used to test the project.
360-
361-
**Snapshots (`snapshots`)**
362-
363-
This folder contains snapshots generated by the test framework when using snapshot testing strategies. It should not be altered manually.
364-
365-
### 📄 &nbsp;`.editorconfig`, `.eslintrc.cjs`, `.prettierrc`, `.size-limit.json`, `.versionrc`, `vite.config.ts`, `tsconfig.json`
366-
367-
These files contain configuration for their eponymous tools:
368-
369-
- [EditorConfig][editor-config];
370-
- [ESLint][eslint];
371-
- [Prettier][prettier];
372-
- [Size Limit][size-limit];
373-
- [Standard Version][standard-version];
374-
- [Vite][vite];
375-
- [Vitest][vitest];
376-
- [TypeScript][typescript].
377-
378-
Any change to those files are welcome but they should be first discussed on our [TypeScript template][template-issue]. Common sense still applies if the project requires some specific changes.
379-
380-
### 📄 &nbsp;`.eslintignore`, `.gitignore`, `.prettierignore`
381-
382-
These files contain ignore configuration for their eponymous tools. Ignore configuration should be based on the one available from `.gitignore` and extended from it.
383-
384-
### 📄 &nbsp;`.gitattributes`
385-
386-
This file contains [attributes](https://git-scm.com/docs/gitattributes) used by Git to deal with the project's files. Our configuration makes sure all files use correct line endings and that lock files aren't subject to conflicts.
387-
388-
### 📄 &nbsp;`CHANGELOG.md`
389-
390-
This file is automatically generated by [Standard Version](https://github.com/conventional-changelog/standard-version) according to commit messages following the [Conventional Commits specification][conventional-commits] whenever a release is made.
391-
392-
### 📄 &nbsp;`CONTRIBUTING.md`, `README.md`
393-
394-
These files contain project's related information and developers (maintainers) documentation.
395-
396-
### 📄 &nbsp;`LICENSE`
397-
398-
This file contains a copy of the project's Apache 2.0 license we use on this project. The Apache 2.0 license has a few more restrictions over the MIT one. Notably (not legal advice), any change by a third party to Apache 2.0 licensed code is required to be stated by the third party. Same applies for changes to the project name by a third party (still not legal advice). For full details refer to the [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0) license text itself.
399-
400-
### 📄 &nbsp;`package-lock.json`
401-
402-
This file is the lock file generated by [npm][npm] to represent the resolved dependencies used by the project. We use npm over [Yarn][yarn] to manage dependencies and only this lock file should be versioned (`yarn.lock` is even ignored to prevent mistakes).
403-
404-
### 📄 &nbsp;`package.json`
405-
406-
The project's package definition file.
407-
408-
**Scripts (`scripts`)**
409-
410-
- `build`: Builds the project;
411-
- `dev`: Builds the project with watch mode enabled;
412-
- `playground:*`: Any command related to the project [playground](#-playground) if any;
413-
- `format`: Runs Prettier on the project;
414-
- `prepare`: npm life cycle script to make sure the project is built before any npm related command (`publish`, `install`, etc.);
415-
- `release`: creates and publishes a new release of the package, version is determined after commit messages following the [Conventional Commits specification][conventional-commits];
416-
- `release:dry`: dry-run of the `release` script;
417-
- `release:alpha`: creates and publishes a new alpha release of the package;
418-
- `release:alpha:dry`: dry-run of the `release:alpha` script;
419-
- `lint`: Runs ESLint on the project;
420-
- `unit`: Runs Vitest on the project;
421-
- `size`: Runs Size Limit on the project;
422-
- `test`: Runs the `lint`, `unit`, `build`, and `size` scripts.
423-
424-
**Minimum Node version supported (`engines.node`)**
425-
426-
The minimum Node version supported by the project is stated under the `engines` object. We aim at supporting the oldest Long Term Support (LTS) version of Node that has still not reached End Of Life (EOL): [nodejs.org/en/about/releases](https://nodejs.org/en/about/releases)
427-
428-
<!-- Links -->
429-
430-
[prismic-docs]: https://prismic.io/docs
431-
[community-forum]: https://community.prismic.io
432-
[conventional-commits]: https://conventionalcommits.org/en/v1.0.0
433-
[npm]: https://www.npmjs.com
434-
[yarn]: https://yarnpkg.com
435-
[editor-config]: https://editorconfig.org
436-
[eslint]: https://eslint.org
437-
[prettier]: https://prettier.io
438-
[size-limit]: https://github.com/ai/size-limit
439-
[standard-version]: https://github.com/conventional-changelog/standard-version
440-
[vite]: https://vitejs.dev
441-
[vitest]: https://vitest.dev
442-
[typescript]: https://www.typescriptlang.org
443-
[template]: https://github.com/prismicio/prismic-typescript-template
444-
[template-issue]: https://github.com/prismicio/prismic-typescript-template/issues/new/choose
445-
[changelog]: ./CHANGELOG.md
446-
[forum-question]: https://community.prismic.io
447-
[repo-issue]: https://github.com/prismicio/prismic-client/issues/new/choose
448-
[repo-pull-requests]: https://github.com/prismicio/prismic-client/pulls
134+
[^1]: This package is maintained by the DevX team. Prismic employees can ask for help or a review in the [#team-devx](https://prismic-team.slack.com/archives/C014VAACCQL) Slack channel.
135+
[^2]: Prismic employees are highly encouraged to discuss changes with the DevX team in the [#team-devx](https://prismic-team.slack.com/archives/C014VAACCQL) Slack channel before starting.
136+
[^3]: Code should be reviewed by the DevX team before merging. Prismic employees can request a review in the [#team-devx](https://prismic-team.slack.com/archives/CPG31MDL1) Slack channel.
137+
[^4]: Prismic employees can ask the DevX team for [npm](https://www.npmjs.com) publish access.

0 commit comments

Comments
 (0)
Please sign in to comment.