[RFC] Respect "engines" in package.json
#7264
Replies: 4 comments
-
|
Globally installed |
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
doneIdeally, everything would work with the local project version of turbo using |
Beta Was this translation helpful? Give feedback.
-
|
I didn't realize you could call files in |
Beta Was this translation helpful? Give feedback.
-
|
Cross-linking a post on the PR: #1361 (comment) As a quick ergonomics fix: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the feature you'd like to request
There is precedent in using the
"engines"property ofpackage.jsonfiles to ensure that globally installed tools of the wrong version cannot be run on a package. Turborepo should support anengines.turboversion constraint that prevents the globally installedturbocommand from running when it does not match.Describe the solution you'd like
When running a
turbocommand globally it should read the rootpackage.jsonfile'senginesproperty and check the version constraint ofengines.turboagainst 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 executeturbocommands is usingpnpm exec. Usingpnpm turbois error-prone sincepnpmwill eat the--filterargument. 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.turboglobal commands to execute the localturbocommand 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.turboto clearly define what is expected here.Beta Was this translation helpful? Give feedback.
All reactions