3 Likes
itâs just that not having a standalone will continue to hurt adoption, split efforts and the community. more professional entities, sites and apps will use alternatives, as they already doâŚ
I donât see how using two repositories instead of one will have any direct impact on three.js adoption, workload, adding more maintainers, professional entities, and the like. This is pretty speculative. Maybe youâre assuming that this new, second repository would do a bunch of other things differently, like porting to TypeScript, and that those changes would have the effects you mention? Letâs be explicit about that if so, because the only immediate effect of a second repository would be to make refactoring harder for the current maintainers. There are reasons many major projects use monorepos, too.
in my opinion i donât think stdlib and forking examples in general is good because it splits efforts. i wish addons was a separate, versioned package with npm compatible modules, optional d.ts annotation types, maintained by a larger group of contributorsâŚ
I kind of agree, but I donât see where this larger group of maintainers is going to come from. Without it, we have the maintainers we have, and a system that works for them. Whatever problems the current system might have, the barrier to opening a PR is pretty low, and I think that has more bearing on three.jsâ success than itâs given credit for.
- patches and features need years to come through, many bugs simply arenât fixed because people may rely on it
This has little to do with project structure and everything to do with maintainer bandwidth. There are not that many active maintainers. I think there are ways to pull out specific addons as separate repositories and let them grow independently. The pmndrs/postprocessing module is a great example of that IMHO, and three-mesh-bvh, and various work on shader composition. Iâd support finding ways to do this more âofficiallyâ perhaps using the three.js github organization. But bifurcating the whole codebase into two repos, core vs. addons, does not have the same effect I think.
it feels like an eternity, seems like 15 but i didnât count, from the first versions on. what i was saying was just that iâve seen people argue about anything with very strong opinions - and later it caved.
from what i observe there are only few people that can review and merge. and they are most definitively overburdened. my question in general is, why do 1-2-3 people need to maintain core three, and then addons, which is largely built by the community anyway. for years we have been told that these are just examples, you need something extra - copy them into your project, make your own changes. but there are hundreds of issues requesting features (even basic things even like programatically telling controls to move to some place, etc.), outstanding prs years old, bugs that are never going to be fixed.
if addons were separate and the group of maintainers could be larger, if devs working on specific features could be added to the roster of maintainers directly, if features could be extended and progress that way, it could be a net positive.
1 Like
in the case of postpro, i think people donât use it because itâs not official. or they donât know about it? three doesnât mention such things anywhere so discoverability for 3rd party is pretty low. mentioning postpro here on discourse also raises eyebrows.
iâm not sure what the solution is, but it feels like if that were part of addons as itâs currently being treated it would only shut him out of his own project and vision. i donât think as an author itâs that enticing.
1 Like
my question in general is, why do 1-2-3 people need to maintain core three, âŚ
If a contributor has a history of maintaining an addon â doing the boring stuff like bug fixes and keeping code health up, in a way that fits with the three.js project â then (at least informally) I think they can usually approve a PR for that file and it will be merged without hassle. When new contributors airdrop a big feature without any history of maintaining that code, then yes, it hits a bottleneck of a small number of people with varying time and priorities. There are other reasons PRs can stall, but at the end of the day someone who is actually going to maintain new code needs to be involved.
âŚthere are hundreds of issues requesting features (even basic things even like programatically telling controls to move to some place, etc.), outstanding prs years old, bugs that are never going to be fixed.
Iâve never seen these things solved any other way than people spending time doing work. If moving addons from one repo to another would bring in 4 new contributors each spending XX hours per week, that would be amazing. But I think thatâs wishful thinking, and a catch-all âaddonsâ repository would have exactly the same maintainers we currently have.
To me, this is a much more interesting line of discussion than an addons repository. I think itâs good in many ways for it to be separate â authors can make big changes without worrying too much about back-compat, and spend their time building something better.
As for âpeople donât use it because itâs not officialâ, yes, but thatâs a tractable problem. There isnât really an active maintainer of the core post-processing stack, so we arenât making progress on important things like HDR support, weâre well aware of that. If/when it feels like a good time to promote pmndrs/postprocessing more directly Iâm happy to push for it, however we want to structure it. And I think it make sense to take a similar approach for other large initiatives within addons, rather than treating addons as a monolith.
1 Like
I donât think itâs pointless.
I understand your stance but i donât understand where itâs coming from.
Have devs ever left the project? I donât know the history of TransformControls but i remember there was some friction. Could this be survivorship bias? You only see a handful of devs around, but donât see the many more who had left the project because they were too exhausted with the library breaking every month?
Also why âaddonsâ? Is this term used anywhere else on npm? The library traverses, transforms and renders a scene graph, you do stuff on that scene graph.
ie. what an addon is in my mind
const renderer = new WebGLRenderer({addons:[OrbitControls, RayTracing, WorldDomination]})
what is not an addon:
import myPackage from './myPackage'
import yourPackage from '@lib/yourPackage'
const renderer = new WebGLRenderer()
const mesh = new Mesh()
myPackage(mesh)
yourPackage(mesh)
mesh.name = 'name'
To reiterate the point - has this changed in the past 10 years?
//these three lines have been here since day one?
const renderer = new WebGLRenderer()
const scene = new Scene()
const camera = new PerspectiveCamera()
// this code is not an "addon" to three.js, it's just code in YOUR application, threejs instantiated above and hasn't changed in 10 years
//------------------------ BEGIN EXAMPLES SETUP -----------------------------//
const someExample = new Example(camera)
const anotherExample = scene.traverse(o=>o.userData.foo = 'foo')
const yetAnotherExample = new PostProcessing()
//------------------------ END EXAMPLES SETUP -----------------------------//
const render = ()=>{
//------------------------ BEGIN EXAMPLES RENDER -----------------------------//
scene.overrideMaterial = myMaterial
renderer.setRenderTarget( myTarget )
renderer.render(scene,camera)
renderer.setRenderTarget( null )
//------------------------ END EXAMPLES RENDER -----------------------------//
//since r1?
renderer.render(scene,camera)
}
The only thing that changed in this particular snippet is how the render target is set on the renderer. This happened once from r1-r150.
Are you a maintainer of three? If not, i think that this is a good example for the topic. You have the power to maintain a collection of packages with hundreds of thousands of downloads, but no power to maintain anything in the library yours relies on? Eg, one of those few maintainers may disagree with your change or simply not have the bandwidth to review it? But they will publish a few breaking changes and introduce new bugs in the meantime (this is the problem).
I think that this proves two points:
- more people get involved if itâs not as centralized as it currently is
- life is made easier for those people if they donât have to shoot at a moving target. Exposing a stable version of a library would show empathy and compassion.
@donmccurdy
Did you have any of these issues here?
Whatever happens, donât stop evolving! 
Sorry if this was already debated or irrelevant,
what about a multi-packages repo (monorepo), something like:
|-- packages/
| |-- three
| `-- three-addons
This would allow:
- having a distinct
@three/addonsnpm package that 3rd-party projects could depend on, on a specific and own version - while staying on the same repo: if
threecore team wants to break things, they can apply those breaking-changes themselves inthree-addons/*files[1]
NB: We could also go farther and have 1 package per addon, but this is still the same idea: keeping a single source-code repo while having multiple distinct npm packages
Wouldnât it be enough?
-
when publishing that new
threemajor version,three-addonsâsthreedep would be bumped and a new minor version also published âŠď¸
1 Like
noone stops you from publishing https://github.com/mrdoob/three.js/tree/dev/examples/jsm as a separate npm package right now?