[RFC] Respect "engines"
in package.json
#7264
Replies: 4 comments
-
Cross-linking a post on the PR: #1361 (comment) As a quick ergonomics fix: |
Beta Was this translation helpful? Give feedback.
-
I didn't realize you could call files in |
Beta Was this translation helpful? Give feedback.
-
Agreed, I had to write a bash script to maintain global turbo versions. #!/usr/bin/env bash
set -euo pipefail
# usage ./global_install turbo
package_json_path="./package.json"
# loop https://stackoverflow.com/a/255913
for dependency in "$@"; do
# extract from package.json https://unix.stackexchange.com/questions/480481/grep-the-name-from-package-json-file#comment1308267_691616
version="$(grep -o "\"$dependency\"\s*:\s*\"[^\"]*" "$package_json_path" | grep -o '[^"]*$')"
# install check https://stackoverflow.com/questions/6480549/install-dependencies-globally-and-locally-using-package-json#comment24765904_10813149
npm list "$dependency@$version" --global > /dev/null 2>&1 || npm install "$dependency@$version" --no-audit --global
done Ideally, everything would work with the local project version of turbo using |
Beta Was this translation helpful? Give feedback.
-
Globally installed |
Beta Was this translation helpful? Give feedback.
-
Describe the feature you'd like to request
There is precedent in using the
"engines"
property ofpackage.json
files to ensure that globally installed tools of the wrong version cannot be run on a package. Turborepo should support anengines.turbo
version constraint that prevents the globally installedturbo
command from running when it does not match.Describe the solution you'd like
When running a
turbo
command globally it should read the rootpackage.json
file'sengines
property and check the version constraint ofengines.turbo
against it's own version. If it does not match it should provide an error and stop executing.Describe alternatives you've considered
pnpm
, the best way to executeturbo
commands is usingpnpm exec
. Usingpnpm turbo
is error-prone sincepnpm
will eat the--filter
argument. This leads topnpm turbo run build --filter={package}
andpnpm turbo run build -- --filter={package}
having very different results. Our solution is to globally installturbo
, however, this can lead to version mismatches with the installed package.turbo
global commands to execute the localturbo
command when one is present. This would be convenient but might result in some ambiguous behavior as opposed to a nice clean error. Even at that though, it's probably still nice to respectengines.turbo
to clearly define what is expected here.Beta Was this translation helpful? Give feedback.
All reactions