What’s new
Three things changed for Next.js projects on Bitrise.
- First, Next.js is now explicitly detected and covered by integration tests..
- Second, Node version detection now reads from the sources your project already uses: .nvmrc, .node-version, .tool-versions, and package.json.
- Third, Node setup is handled declaratively, replacing the outdated asdf install script that was previously added to workflows.
What problem are we solving
There was no way to tell on the Bitrise side that your project was Next.js. This meant that your project wasn’t fully covered by Bitrise and that no tests were written for it by default. If your project happened to work, it was incidental.
Additionally, Next.js projects pin their Node version in .nvmrc, .node-version, .tool-version, or package.json. Bitrise didn’t read those files, so the generated config and your local environment could silently diverge. The mismatch only surfaced when something broke in CI.
What the solution looks like
The scanner now detects Next.js projects by checking for next in your dependencies. It also excludes .next directories when scanning, so build output from a previous Next.js build never produces false matches.
Node version detection now reads from your project files in priority order: .nvmrc, .node-version, .tool-versions, and the engines.node field in package.json. When a version is found, it is written into a tools: { node: } block in the generated bitrise.yml, with no explicit install step needed. When no version is found, the stack’s default is used.
One thing to be aware of: Next.js projects are detected and supported, but Bitrise does not have a dedicated Next.js project type. Your project will be classified and labelled as node-js throughout Bitrise. The framework detection is informational for now and does not change the shape of the generated workflow.
How to use it
No action is required. The next time you scan your Next.js project, the scanner detects it automatically and generates the appropriate config.
Docs
C