You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Node.js, Starship provides the variableversion and the optionsstyle and not_capable_style. version is the version of the installed Node.js and it is displayed using the format specified in style when it matches the version specified in package.json (property $.engines.node) or using the format specified in not_capable_style when it does not match.
This is helpful in itself but it could be more helpful than than. When the version of the interpreter does not match the project requirements, the first execution of any yarn command in the directory tells not only that the current version of Node.js is not appropriate for the project but it also tells what version is expected.
Starship could bring the same information without even running yarn.
It already knows what is written in package.json and has the information in memory. This is how it detects if the current version of Node.js is good or not and decides to render it using style or not_capable_style. All it needs is to provide a variable similar to version that contains the Node.js version required by the project (the value of property $.engines.node from package.json).
Please add a new variable (it could be named expected_version) that contains the value of property $.engines.node from package.json).
A similar solution can be implemented for other languages that declare the version of the interpreter that they need to run (PHP, Python, Ruby etc.)
The text was updated successfully, but these errors were encountered:
It would be useful to show only version if the Node.js version matches the version expected by the project and to show both version and expected_version if the version of the interpreter does not match the requirements of the project.
Sounded straightforward so I tried this~ Currently have a working implementation, shows expected version if engines.node and current node version don't match, and if the variable is included in the module format. Not including the $expected_version variable in format doesn't change the normal rendering.
Was thinking about adding an option to allow people to enable/disable it but if you don't put the variable in format then it won't show regardless? Just have to clean some stuff up.
Feature Request
For Node.js, Starship provides the variable
version
and the optionsstyle
andnot_capable_style
.version
is the version of the installed Node.js and it is displayed using the format specified instyle
when it matches the version specified inpackage.json
(property$.engines.node
) or using the format specified innot_capable_style
when it does not match.This is helpful in itself but it could be more helpful than than. When the version of the interpreter does not match the project requirements, the first execution of any
yarn
command in the directory tells not only that the current version of Node.js is not appropriate for the project but it also tells what version is expected.Starship could bring the same information without even running
yarn
.It already knows what is written in
package.json
and has the information in memory. This is how it detects if the current version of Node.js is good or not and decides to render it usingstyle
ornot_capable_style
. All it needs is to provide a variable similar toversion
that contains the Node.js version required by the project (the value of property$.engines.node
frompackage.json
).Please add a new variable (it could be named
expected_version
) that contains the value of property$.engines.node
frompackage.json
).A similar solution can be implemented for other languages that declare the version of the interpreter that they need to run (PHP, Python, Ruby etc.)
The text was updated successfully, but these errors were encountered: