I am looking for some help with a Hilla evaluation for our project and, after bootstrapping a Hilla project with version 2.1.3 and adding Nx 19 on top, ‘npm install’ shows a dependency resolution error:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: no-name@undefined
npm ERR! Found: @vitejs/plugin-react@4.2.1
npm ERR! node_modules/@vitejs/plugin-react
npm ERR! dev @vitejs/plugin-react@“4.0.0” from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! dev @vitejs/plugin-react@“4.0.0” from the root project
npm ERR!
npm ERR! Conflicting peer dependency: vite@4.3.9
npm ERR! node_modules/vite
npm ERR! peer vite@“^4.2.0” from @vitejs/plugin-react@4.0.0
npm ERR! node_modules/@vitejs/plugin-react
npm ERR! dev @vitejs/plugin-react@“4.0.0” from the root project
Solving manually the conflict in the package.json by changing the versions to:
“vite”: “^5.0.0” (from “vite”: “4.0.0”) and “@vitejs/plugin-react”: “4.2.1” (from “@vitejs/plugin-react”: “4.0.0”) and removing the package-lock.json makes ‘npm install’ to succeed but it later fails when executing ‘:bootRun’ as it seems to restore the previous conflicting versions before running ‘npm install’ again itself.
Some questions:
is it possible to use Hilla 2.1.3 with Nx 19?
if not, is it possible to use Hilla 2.1.3 with vite 5?
if not, is it possible to avoid ‘:bootRun’ restoring the package.json versions before doing a ‘npm install’?
why are the versions set to “fixed versions” instead of “compatible versions” (i.e.: “vite”: “4.0.0” vs “vite”: “^4.0.0”)?
Just the obvious question: did you try the latest versions? Hilla 2.1.3 seems kinda odd and I doubt that’s it is compatible with vite 5 looking how “old” it is.
Hilla 2.5.x is using Vite version 5.0.6. Whether Hilla can be used with Nx I can’t say. The whole idea of Hilla is that you should not actually touch that much the tool chain. It is one of the ideas of Hilla, that instead of maintaining tool chain yourself, you just use what the framework defaults are.
As for “why are the versions set to “fixed versions” instead of “compatible versions” (i.e.: “vite”: “4.0.0” vs “vite”: “^4.0.0”)?”
My guess is that in real life, products do not respect semantic versioning rules consistently enough to guarantee no breakages; like Tatu said, it’s the framework’s job to maintain the build chain and other related libraries so developers can focus on application code.
I used https://start.spring.io/ to create a new project and 2.1.3 is the version configured there. I guess that the Gradle initializer is not updated on every Hilla release.
After reading your post, I went to the Gradle plugin portal and found that the last Hilla version announced there is 24.1.5: Gradle - Plugin: dev.hilla. I guess version “24.1.5” was an error while publishing and that version has been removed but is still shown as latest.
Then I picked version 2.5.7 (latest available in the versions list from the Gradle plugin portal) and needed to upgrade the Gradle version in the Gradle wrapper from 7.6.1 to 8.4. The reason was a Java 21 requirement (File version 65) when using 2.5.7 (it can be due to my current Java setup, but I decided to upgrade nevertheless).
After doing all that, my skeleton project is now working.
I see an “overrides” section in the “package.json” file with quite some dependencies and also a “vaadin” section with more dependencies inside. Do you know what that is for in Hilla and if it is documented somewhere? My goal is to understand how to properly override a package version is absolutely necessary (i.e. critical security issue found).
As explained in my response to Christian, I managed to upgrade and have my hello world project working with Nx 19. It also seems that Hilla is itself built with Nx (Nx config files are present in the GitHub repo) but I still need to figure out myself how a Hilla project would fit in our monorepo.
I agree that the goal of Hilla managing the toolchain for you is a great idea. That is very valuable most of the times but there some occasions where one would need to override a dependency version. For instance, in the case that a critical security vulnerability has been reported. In that case, it is very likely that you would need to patch that version and make an urgent release of your project. Relying on an open source framework to release a new version fixing it is not a good solution and most times a showstopper for adoption.
I am now trying to understand how Hilla manages the package.json file and if there is already a proper mechanism in Hilla to patch a package version.
While in real life it is fair to expect that not every project follows semantic versioning right, in the case of projects like vitejs, I would expect that they do it. If the version used was “^4.0.0” instead of “4.0.0”, fixing a vulnerability issue would be as easy as removing the “package-lock.json” file and re-installing packages.
As mentioned to Tatu, I would be interested in finding out if Hilla has a concept for overriding package versions.
When establishing a new project, if package.json (or equivalen files when using npm or pnpm) does not exists, our plugin will generate a default one. We have some dependencies there with fixed version and some open ended. This is based on what we have learned about their stability. We want it to be such that it is known to work.
When you update Vaadin / Hilla version the plugin will overwrite some of the versions, especially the framework components etc. Also we may change main dependent library versions such as Lit, React … Also if we have decided to update the tooling, the needed versions are updated.
But your own set dependencies are not touched. The idea is to support normal frontend practice of adding dependencies to project with “npm” command line commands.
If you just keep building application you can manually change versions in package.json if there is compelling need to. Of course then you need to know that version you will is compatible with any other stuff you have in the project.
Also noting, that in case of vulnerable dependencies, we have SBOM management ourside and keep updating those versions in our new releases. So if you do change version managed by us, the next time you change Vaadin / Hilla version, the version can be overriden by us. But understanding your case, it should not be a problem.