backstage: backstage-cli versions:bump is stuck unable to upgrade with Node16 and fails with Node18 🐛 Bug Report:

📜 Description

I’m stuck on backstage 1.8.3. versions:bump calls fail for nodejs 16 and 18.

I’ve seen https://github.com/backstage/backstage/issues/20881 & https://github.com/backstage/backstage/issues/14697, neither one allows for an answer that gets yarn backstage-cli versions:bump to work.

yarn backstage-cli versions:bump --release 1.9.1
yarn run v1.22.19
error root@1.0.0: The engine "node" is incompatible with this module. Expected version "14 || 16". Got "18.19.1"
error Commands cannot run with an incompatible environment.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

So, I change to 16… and I get this error error @azure/identity@4.0.1: The engine "node" is incompatible with this module. Expected version ">=18.0.0". Got "16.20.2" more context…

yarn backstage-cli versions:bump --release 1.9.1
 ...
warning workspace-aggregator-17f6cff2-115e-4ef9-b7ed-84e6ecb676af > backend > @backstage/plugin-scaffolder-backend > @backstage/plugin-scaffolder-backend
-module-gitlab > @gitbeaker/node@35.8.1: Please use its successor @gitbeaker/rest
warning workspace-aggregator-17f6cff2-115e-4ef9-b7ed-84e6ecb676af > backend > @backstage/plugin-catalog-backend > @backstage/repo-tools > @microsoft/api-
extractor > @rushstack/node-core-library > z-schema@5.0.6: has issues with node 14
[3/5] Fetching packages...
warning Pattern ["app@link:packages/app"] is trying to unpack in the same destination "/home/<REDACTED>/.cache/yarn/v6/npm-app-0.0.0/node_modules/app" as pa
ttern ["app@0.0.0","app@0.0.0"]. This could result in non-deterministic behavior, skipping.
error @azure/identity@4.0.1: The engine "node" is incompatible with this module. Expected version ">=18.0.0". Got "16.20.2"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Command 'yarn' exited with code 1

👍 Expected behavior

yarn backstage-cli versions:bump --release 1.9.1

with no errors

👎 Actual Behavior with Screenshots

current backstage version is 1.8.3 (you can see everything you need in the description)

👟 Reproduction steps

have a 1.8.3 based backstage project
ensure git status shows no changes
set your Node version to 16.20.2
yarn backstage-cli versions:bump --release 1.9.1
try upgrading with nvm to 18
run yarn backstage-cli versions:bump --release 1.9.1 again
told now that you need node 16

📃 Provide the context for the Bug.

No response

🖥️ Your Environment

No response

👀 Have you spent some time to check if this bug has been raised before?

I checked and didn’t find similar issue

🏢 Have you read the Code of Conduct?

I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

About this issue

Original URL
State: closed
Created 4 months ago
Comments: 22

Most upvoted comments

Thanks for sharing these details @alfred-stokespace 👍

Let me try and answer your questions:

So, perhaps I made a mistake choosing Backstage? I’d like to think that Backstage creators had hoped to be capable of being supported by small startups with perhaps a single dev feeding it. Did I make a mistake? I’d like to hear your thoughts on this topic.

For context I’ve been been personally involved with the project for about 3 years now, we initially ran off a fork due to some bugs, which have since been fixed, using it with Azure DevOps Server. I was the only one maintaining Backstage at a small to mid-size organization. Given my experience having a single Dev maintaining it is very realistic and also fairly common as a starting point. Each Org can be different and it may stay a single person for a while or they may invest and grow the team.

Is Backstage a bad idea for only updating once/twice a year? If y’all expected it more often I’d say that’s a pretty heavy burden my dear fine backstage folks.

Backstage is still in active development and evolving. There are releases every month with worth while features that Adopters are looking to use. Due to this only upgrading Backstage once or twice a year is going to lead you to the pain you’ve experienced. Once we moved off the fork one of the first things I did was create an automated job that would do the version bump, create a branch, commit the changes, and open a pull request. I’d have this run the day after the release early in the morning and then all I had to do was review it and look at the change log. What previously took me a day was down to about 15-45 minutes. I’m not sure what CI/CD tooling you are using but we have similar automation setup for the Backstage Demo site, the workflow is here: https://github.com/backstage/demo/blob/master/.github/workflows/version-bump.yml and here’s an example PR: https://github.com/backstage/demo/pull/326

I opted to use Backstage (rather than create a custom website) because I didn’t want to write all the integrations (which are very useful) as well I didn’t want to start form zero on UI and application framework. I liked that I could start within a foundation and add pages/backends without having to do that design work and implementation ahead of time.

Yes, this is all reasonable reasons to adopt Backstage and why many Orgs do. I know it was where we were - build it all or use Backstage as a starting point. 🚀

Hope that helps?

awanlin on Mar 11, 2024