Hello everyone, I’m new to this project and very excited to use this awesome package!
While looking at the codebase to create new PR, it was really weird at first glance that there were no runtime dependency inside the package.json.
So I searched for the CONTRIBUTE.md and README.md but couldn’t find the clue about the reason why there are no external dependencies at all.
Is there any specific reason about this or the project policy link that I should follow while contributing to this repo? If so please let me know.
It sounds like you consider it to be some kind of deficiency to not have any dependencies, while it is actually an asset to not depend on anything, and be self-contained, so to speak.
In any case I expect a PR you submit which would introduce one or more dependencies to be rejected, for that reason alone.
3 Likes
I’m not aware of any written explanation of the decision. three.js began around the same time as npm itself, and then dependencies in JavaScript were … not really a well-defined concept … so I suspect it was the obvious and convenient choice to avoid them at the time.
Now in 2025, obviously dependencies are more normalized in the JavaScript ecosystem. But I’m not sure the core library would be any better for having runtime dependencies – complexity and scope have remained manageable for a self-contained library, and maintaining the dependencies does have some cost. Addons (three/addons/*) do have dependencies handled in different ways – mainly vendoring – because adding npm dependencies to the core library to support addons would not make much sense. For addons complex enough to require major dependencies and a build toolchain (GitHub - ThatOpen/engine_components is a good example), it makes more sense to maintain those in a separate repository.
2 Likes
Thank you! Now I understand the concept more precisely. I didn’t knew there was some kind of historical reason 