1 year ago

#151802

test-img

Christian Dräger

How to build yarn or npm project without actual instalation of yarn/npm/node

TL;DR:

Is it possible to build a project with a certain yarn version (defined as part of the project) without having yarn,npm or node globally installed on my local machine?

Does an Gradle/Maven-Wrapper equivalent exist for yarn/npm?

Prosa:

while not working continuously on frontend projects and thereby not having bigger attention on always having latest node and yarn installations on my dev machine, i have been forced to upgrade my local installation of node due to some dependency upgrades. so far so good, not an big use, BUT: at this point, while comparing it to related build tools that are mainly used for backend/JVM related projects like gradle or maven that come up with a so called wrapper approach, where the needed binaries etc that are neccessary to run these tools, are then part of the project (a certain version that is defined by the project will be downloaded into the project) instead of beeing an installation on every local dev machine (taht usually diverge), i am asking myself if something equal exist for node and/or yarn.

Why:

in my opinion the advantages of the “wrapper- / portable installations approach” that some build-tools provide in terms of developer experience and simplification of the prerequisites needed on a devs machine (or any other machine like a CI server or inside a Dockerbuild file etc) are just great, because:

  • the possibility to run a build/test/… with a specified version and settings without an actual installation
    • therby reduce ramp-up phase for new devs
    • no extra shizzle needed in execution environment
  • tools version and settings are part of the project and thereby provides the same version to different users, and the execution environment is as simple as changing the Wrapper definitionit’s. which means it is ensured that every developer is working on the same version to avoid different behaviour/errors/breaking changes or forcing changes to the machines itself (installations, updates etc) on devs machines which in turn leads to more reliable and robust builds
  • since settings are part of the project, they are under version control one can bump to latest tooling for the whole project/team, all other devs just pull and done

Known workarounds:

  1. In mixed projects (mono repo including frontend and backend) that rely on gradle or maven tooling anyway i am usually using a node plugin that leads to the described wrapper-behaviour (automatically downloading a defined node and yarn version into the build folder and execute frontend builds against this). but putting a gradle build file and a gradle wrapper into a dedicated frontend repo feels a bit odd to me and would force dedicated frontend devs to use gradle which they are probably not feeling comfortable with + this approach requires a java installation, not really a step forward.

  2. Other approach i could imagine is placing a dockerfile that inherits yarn from a base image and mounts the project folder, then build everything by the use of this dockerfile. pro: everyone would use a certain yarn version that is defined as part of the project. con: cn not use familar yarn commands anymore / feels like building a wrapper on our own

node.js

npm

yarnpkg

gradlew

build-tools

0 Answers

Your Answer

Accepted video resources