When selecting a technology stack for a new project, we all look for frameworks and libraries that can speed up delivery and simplify our lives. Sometimes, in our eagerness to streamline things, we overlook the implications that may arise as our project grows significantly bigger.
Recently, our team was working on porting part of an existing Vue.js application’s functionality into an existing Chrome Extension. Even though the extension was built on top of the Quasar Framework, it mostly used the framework as a convenient extension-building pipeline without utilising many of the components it provided. The porting process, which was supposed to be a walk in the park, turned out to be a challenging endeavour, akin to scrambling through jungles. And this is what was lurking in the darkness…
Mismatched Vue.js Versions
The first major issue we encountered was a mismatch in Vue.js versions. From Vue version 3.4.15 onwards, recursive (cross-dependent) computed properties caused — surprise-surprise — recursion, leading to rendering failures with non-obvious errors.
To identify the problem, we commented out blocks of code until we found the few lines causing all the trouble. These components were originally developed with Vue 3.2 and 3.3, so no issues had been observed before. We resolved this by explicitly specifying Vue version 3.3 in the dependencies, as version 3.4.14 also proved incompatible.
Hindsight Wisdom
It is definitely worth remembering the main aspects of a consistent dependency management approach. Using the following practices during development helps maintain the project’s health:
1. Install Dependencies with Exact Versions
// package.json
"dependencies": {
"vue": "3.3.0",
"quasar": "2.0.0"
} 2. Use a Lockfile
Ensure your project includes package-lock.json or yarn.lock.
3. Run Deduplication
npm dedupe 4. Set Up CI Pipeline
Create a CI pipeline that runs on every commit, installing dependencies and running tests to catch issues early.
5. Document and Communicate
Maintain a README.md with dependency version information and update protocols.
These recommendations are easy to follow and minimise the risk of version mismatches down the line.
Transient Dependency and Package Duplication
The next problem involved an emoji picker. Attempts to open it resulted in the error “[Vue warn]: resolveComponent can only be used in render() or setup()”.
To address this unfamiliar error, we turned to the vastness of the Internet for possible root causes and soon found a clue: multiple instances of Vue. Running “npm explain vue” confirmed our suspicion, revealing two versions of Vue in the project’s dependency tree. Following a recommendation, we used “npm dedupe” to remove the Vue version inherited from the emoji picker package, thus resolving the error. It was a classic “dependency of a dependency” problem, also known as “transient dependency”, where new components and libraries introduce hidden dependencies.
It’s useful to refer to tools like npm’s “npm ls” or Yarn’s “yarn why” to identify and troubleshoot transient dependency-related issues. Ignoring such problems may lead to version conflicts, project bloat, or even unexpected behaviour (aka “magic”).
Did We Even Need Quasar?
This experience reinforced the old mantra, “There is no silver bullet”. Initially, using a framework like Quasar can save development time by simplifying common tasks and providing predefined behaviour. However, as the project grows and complexities arise, the framework can start to “resist”, making it harder or even impossible to achieve your goals.
In our case, we had to supply fake CSS style files to override the default styles added by Quasar, which wasn’t an elegant solution. Additionally, Quasar did not support creating a proper build pipeline for the extension’s offscreen page. So, metaphorically speaking, opting for a trusted pair of old scissors instead of a fancy Swiss knife would have been more apt. The right tool for the right job can make all the difference.
Choose your software development tools wisely 😉
