Please rationalize dependencies across packages and keep them aligned.

[stefanobartoletti]

Hi everyone, I'm reporting something that looks a bit strange to me, but that may or may not be an issue in a general sense.

First of all, I'm using Tres by including it in my Nuxt project with the provided @tresjs/nuxt module (latest published version)

I started to notice some odd behavior some time ago, I'm experiencing a strange little problem that is preventing Levioso and MouseParallax (from the cientos package) to work in the development environment, while they still work in the built site in SSR mode. I already described it here, but I was not able to provide more info as no console errors were logged, so I was left in the pure speculation field: Tresjs/cientos#369

Now I noticed that after upgrading typescript in my project from 5.4.3 to 5.4.5, both Levioso and MouseParallax are broken also in the built production site, just like in the development. I'm not sure what is happening under the hood.

I tried to delve a little more in the dependencies, and noticed that there is something that looks odd in the versioning of the packages provided by TresJS.

TresJS core has the following versions:

"@types/three": "^0.160.0",
"three": "^0.161.0",

Tres Cientos has

"@types/three": "^0.161.2",
"three": "^0.161.0",
"typescript": "^5.3.3"

and Tres Nuxt has

"@types/three": "^0.160.0",
"three": "^0.161.0",
"typescript": "^5.3.3"

and since all of them require three as a peer dependency, that I had to manually install on my project, I have this:

"three": "^0.163.0",
"typescript": "^5.4.3"

I'm not really sure of the inner workings of all TresJS packages (maybe this is not related to my issues), but it seems to me that these mismatches have indeed some effect, especially since I noticed some worsening when trying to upgrade typescript.

I would suggest keeping dependencies in these three (excuse the pun!) packages aligned to the same version, and maybe keep also @types/three aligned with the base three. Also, if this is possible, I would also suggest including three as a direct dependency of TresJS core instead of placing it as a peerDep, to ensure that the end user is not accidentally installing and using a different version than the one used internally by Tres (it may happen if a new Three version is released after the latest Tres).

I hope that this does not sound like a nuisance, I understand that maintaining a project like this is not easy. I just wanted to report my experience and try to give some insight into what I thought could be possible causes and solutions. Thanks for all the work that is being done here 💚

[alvarosabu]

Hi @stefanobartoletti, thanks for reporting this and for the thoughtful discussion. It’s always valuable to hear user experiences and suggestions.

Regarding the ecosystem setup, each repository treats several dependencies as peer dependencies, which are then optimized using Vite during the build process. For instance, you can see our approach in our Vite configuration here:

tres/vite.config.ts

Lines 74 to 89 in 456f997

	external: ['vue', '@vueuse/core', 'three'],
	output: {
	exports: 'named',
	// Provide global variables to use in the UMD build
	// for externalized deps
	globals: {
	'vue': 'Vue',
	'@vueuse/core': 'VueUseCore',
	'three': 'Three',
	},
	},
	},
	},
	optimizeDeps: {
	exclude: ['vue', 'three'],
	},

This ensures that even if different local versions of Vue or Three.js are used, a consistent version is maintained during the build.

We also ensure that @tresjs/core is deduplicated across packages to prevent version conflicts, as shown here:

https://github.com/Tresjs/cientos/blob/f897c33c8c5a9d1560b94c08157f0cc0a3a770ae/vite.config.ts#L21C3-L23C5

Regarding the suggestion to include three as a direct dependency rather than as a peer dependency: While this could potentially simplify dependency management, one of our key considerations is the impact on the final bundle size. Three.js is not fully tree-shakeable, meaning including it directly could lead to significantly larger bundle sizes for all users, regardless of whether they use all of its features. By maintaining it as a peer dependency, we allow users to manage which parts of Three.js they include, thus optimizing their bundle size based on their specific needs.

This strategy is crucial for maintaining the flexibility and performance of applications built with TresJS. We will continue to monitor this setup and consider user feedback for future updates.

I agree we should try as much as possible to maintain the dependencies across the ecosystem with the same versioning, but since different teams are working on the packages we opted to use vite deduping and optimizeDeps to reduce problems.

Regarding nuxt.

The Nuxt module has two major features

• Creates an SSR-safe version of the TresCanvas to work with. (uses .client under the hood)
• It detects which sub-packages (cientos, post-processing are installed and adds them to auto-import

We have this issue constantly between Nuxt and the core, with cientos as well, last new version of Nuxt the main loop useRenderLoop stopped working when doing SSG we need to investigate further, but it's more a Nuxt thing. We don't have these issues with dependencies and cientos when using just Vue.

Regarding your issue with Levioso and MouseParallax, are you importing them manually or relying on the autoimport of the module? Di you try on ssr=false

If still doesn't work lets open a ticket on the nuxt package with your system info an a reproduction so I can take a look to it 💚

[alvarosabu]

Hi @stefanobartoletti I just saw that you opened a ticket already here that was closed Tresjs/cientos#369

I just downloaded the code on https://github.com/stefanobartoletti/tresjs-playground and run pnpm run dev and both Levioso and MouseParallax are working as expected on clean install

Screen.Recording.2024-04-15.at.18.56.12.mov

[stefanobartoletti]

Hey @alvarosabu thanks for the detailed answer 🙏🏻

Now I understand a little better the overall setup, and probably the issue is with my current implementation.

I'm not really sure anyway, as in my public playground, the one that you also linked in your previous answer, everything is working fine.

I had these problems with another project whose code is not public, but it has many more modules loaded, so I think that my best option is to start from scratch and add one thing at a time and see when things break.

I will see to do this as soon as I gather the required time :D