Follow-up on https://github.com/vercel/next.js/pull/37193
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
We have tests running on the examples repository that will fail if `name` or `version` is found in the `package.json`. We should make it more clear in the documentation to omit these fields.
@ijjk
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
* Add note to contributing about docs manifest
* Update contributing.md
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Balázs Orbán <info@balazsorban.com>
This PR updates the docs and examples for `create-next-app` to include pnpm usage.
The following script was used to update every example README:
```js
const fs = require('fs')
const examples = fs.readdirSync('./examples')
for (let example of examples) {
const filename = `./examples/${example}/README.md`
const markdown = fs.readFileSync(filename, 'utf8')
const regex = new RegExp(`^yarn create next-app --example (.*)$`, 'gm')
const output = markdown.replace(regex, (yarn, group) => {
const pnpm = `pnpm create next-app -- --example ${group}`
return `${yarn}\n# or\n${pnpm}`
})
fs.writeFileSync(filename, output)
}
```
contributing.md file still refers `master` branch name since the branch renamed as `main` recently. This PR contains a fix for that.
**related:**
#33153#33198
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
* Remove prebuilt binaries from repo
* Prefer locally built binary
* Add binary packages as optionalDependencies
* Remove build-native workflow for prebuilt binaries
* Remove binaries from checkCompiled job
* Change build-native command to default to dev
* Add build-native-dev and have tests depend on it
* Update contributing
* Run ls to make inspect artifact download
* Use correct artifact download path
* Try using reusable workflows
* Resort to duplication for now
* Inspect artifact download
* Ensure native is copied for PR stats
* Copy after ref checkout and log binaries for PR stats
* fix typo
* copy right before linking/packing
* Use fs.copy
* fix test for now
Co-authored-by: jj@jjsweb.site <jj@jjsweb.site>
I originally sought out to add a statement about chromedriver before investing time in making the document as clear as possible for new contributors on the first read. Any notes are very welcome.
- add Ubuntu/Debian `apt install chromedriver` tip
- consistent heading names, subheadings
- formatting
- order changes:
1. Developing
2. Building
3. Testing
4. Adding warning/error descriptions
5. Adding examples
## Documentation / Examples
- [x] Make sure the linting passes
## Feature
I was struggling to get my local dev build working as a local package.json override, and types do not seem to be generated by `yarn dev`, so I had to figure out a cohesive way to build the project start-to-finish (and also clean the project).
Building the project and all types ended up just being `yarn prepublish`, here aliased as `yarn build`, and I added a `yarn clean` script. These two together should make it very difficult for any contributor to be confused how to generate a final build including all type declarations.
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
b2a888c144/contributing.md (building)
This Pull Request adds [Alex](https://alexjs.com/) to our documentation. It catches insensitive, inconsiderate writing.
The original PR (https://github.com/vercel/next.js/pull/25821) is too large so I have decided to break it down into smaller PRs. This PR is the first part. Then I will continue to add the rest of the documentation in smaller PRs.
## More Information on Alex:
https://alexjs.com/https://github.com/get-alex/alex
## Documentation / Examples
- [x] Make sure the linting passes
* docs: use descriptive links instead of "click here"
Linking text such as "here" or "click here" is not accessible (and
doesn't look that great either). The best example of why it's better to
use link text that provides context is that some screen readers allow
navigation by links alone. If all links say "click here", then how does
the user know which one to go to?
I tried to make the minimal change necessary to make the link text
descriptive but had to reword a few sentences that didn't read well.
* Apply suggestions from code review
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR adds a `Preview` section and a `Open in StackBlitz` button to various examples. I have tested all examples and omitted the ones that require third party API keys, or didn't work. Some examples don't work locally either.
Here's an example:
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [x] Examples updated
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [x] Make sure the linting passes
* Find/Replace "Deploy it to the cloud..."
* Find/Replace "Deploy it to the cloud..." (no colon)
* Find/Replace "Deploy it to the cloud..." for firebase
* Convert remaining ones
* Storybook deployment
* Update with-stripe-typescript
* Update contributing.md
* Remove `now`
* Update examples/with-stripe-typescript/README.md
Co-Authored-By: Luis Alvarez D. <luis@zeit.co>
