rsnext/packages/next/cli/next-info.ts

114 lines
3.1 KiB
TypeScript
Raw Normal View History

#!/usr/bin/env node
import os from 'os'
import childProcess from 'child_process'
import chalk from 'next/dist/compiled/chalk'
import arg from 'next/dist/compiled/arg/index.js'
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
import fetch from 'next/dist/compiled/node-fetch'
import { printAndExit } from '../server/lib/utils'
import { cliCommand } from '../lib/commands'
import isError from '../lib/is-error'
function getPackageVersion(packageName: string) {
try {
return require(`${packageName}/package.json`).version
} catch {
return 'N/A'
}
}
function getBinaryVersion(binaryName: string) {
try {
return childProcess
.execFileSync(binaryName, ['--version'])
.toString()
.trim()
} catch {
return 'N/A'
}
}
const nextInfo: cliCommand = async (argv) => {
const validArgs: arg.Spec = {
// Types
'--help': Boolean,
// Aliases
'-h': '--help',
}
let args: arg.Result<arg.Spec>
try {
args = arg(validArgs, { argv })
} catch (error) {
if (isError(error) && error.code === 'ARG_UNKNOWN_OPTION') {
return printAndExit(error.message, 1)
}
throw error
}
if (args['--help']) {
console.log(
`
Description
Prints relevant details about the current system which can be used to report Next.js bugs
Usage
$ next info
Learn more: ${chalk.cyan(
'https://nextjs.org/docs/api-reference/cli#info'
)}`
)
return
}
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
const installedRelease = getPackageVersion('next')
console.log(`
Operating System:
Platform: ${os.platform()}
Arch: ${os.arch()}
Version: ${os.version()}
Binaries:
Node: ${process.versions.node}
npm: ${getBinaryVersion('npm')}
Yarn: ${getBinaryVersion('yarn')}
pnpm: ${getBinaryVersion('pnpm')}
Relevant packages:
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
next: ${installedRelease}
eslint-config-next: ${getPackageVersion('eslint-config-next')}
react: ${getPackageVersion('react')}
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
react-dom: ${getPackageVersion('react-dom')}
`)
try {
const res = await fetch(
'https://api.github.com/repos/vercel/next.js/releases'
)
const releases = await res.json()
const newestRelease = releases[0].tag_name.replace(/^v/, '')
if (installedRelease !== newestRelease) {
console.warn(
`${chalk.yellow(
chalk.bold('warn')
)} - Latest canary version not detected, detected: "${installedRelease}", newest: "${newestRelease}".
Please try the latest canary version (\`npm install next@canary\`) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue`
)
}
} catch (e) {
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
console.warn(
`${chalk.yellow(
chalk.bold('warn')
)} - Failed to fetch latest canary version. (Reason: ${
(e as Error).message
}.)
Detected "${installedRelease}". Visit https://github.com/vercel/next.js/releases.
Make sure to try the latest canary version (eg.: \`npm install next@canary\`) to confirm the issue still exists before creating a new issue.
feat: improve opening a new issue flow (#34434) Ref: [Slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1645003443213449) When opening a new issue, it is desired that the user has checked if the `canary` release not already have fixed their issue, since we do not backport fixes to previous Next.js versions. - added a CLI warning when `next info` runs that looks like this: ![image](https://user-images.githubusercontent.com/18369201/154309275-01ccc979-01e5-4ccb-8a22-5deab64765a0.png) This links to a message docs page with more information and some useful links. - refactored our bug report templates to be more clear and removed the fields that are now unnecessary (since running `next info` is expected to run on releases that already have it) - Made browser/deployment optional, as in most cases those fields are irrelevant. We still ask them, but mention that they are only needed if relevant. - Asking for the exact browser version now ## 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` Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-02-16 18:45:01 +01:00
Read more - https://nextjs.org/docs/messages/opening-an-issue`
)
}
}
export { nextInfo }