Skip to content

Conversation

@khaled-maruf
Copy link
Contributor

  • this makes the version checker a bit more robust and use a default node version for any major version over 1, so that we don't have to handle them seperately everytime.
  • this also reads the version from the package.json engine property which makes it more dynamic and let the client repo have control from their end for overrides.

- this makes the version checker a bit more robust and use a default node version for any major version over 1, so that we don't have to handle them seperately everytime.
- this also reads the version from the package.json engine property which makes it more dynamic and let the client repo have control from their end for overrides.
@khaled-maruf khaled-maruf changed the title OCP-1512: make the node version detemination robust OCP-1512: make the node version determination robust Nov 18, 2025
Copy link
Collaborator

@pawelziebaopti pawelziebaopti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's discuss this approach. this change would force us to bump minimal node version to the one we want to target by the engine. I'm not sure if that's a good approach as it would force us to bump min node versions for all our libs and tools. this can be problematic for tools like ocp-cli, which have app-sdk dependency, but we want to support multiple engine versions. this is the reason we kept node18 as min version for node-sdk and app-sdk.

@khaled-maruf
Copy link
Contributor Author

khaled-maruf commented Nov 18, 2025

let's discuss this approach. this change would force us to bump minimal node version to the one we want to target by the engine. I'm not sure if that's a good approach as it would force us to bump min node versions for all our libs and tools. this can be problematic for tools like ocp-cli, which have app-sdk dependency, but we want to support multiple engine versions. this is the reason we kept node18 as min version for node-sdk and app-sdk.

I'm wondering if we should try to remove the app-sdk and node-sdk dependencies completely from the CLI, My hunch is that we're only using some type definitions from those, which we can override using typescript hacks, that'd let us upgrade our components independent of each other.

Should I remove the NODE_ENGINE read from the package.json from here? And hard code version 3 entry for the package itself?

@pawelziebaopti
Copy link
Collaborator

let's discuss this approach. this change would force us to bump minimal node version to the one we want to target by the engine. I'm not sure if that's a good approach as it would force us to bump min node versions for all our libs and tools. this can be problematic for tools like ocp-cli, which have app-sdk dependency, but we want to support multiple engine versions. this is the reason we kept node18 as min version for node-sdk and app-sdk.

I'm wondering if we should try to remove the app-sdk and node-sdk dependencies completely from the CLI, My hunch is that we're only using some type definitions from those, which we can override using typescript hacks, that'd let us upgrade our components independent of each other.

Should I remove the NODE_ENGINE read from the package.json from here? And hard code version 3 entry for the package itself?

as discussed, I agree it makes sense to remove dependencies to app-sdk and node-sdk from ocp-cli.

@khaled-maruf khaled-maruf merged commit c341668 into master Nov 18, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants