Alternatives to destiny (project seems abandoned)

[kachkaev]

Hey folks! 👋 I‘ve been a fan of the ‘fractal tree’ approach since @benawad‘s youtube talk on destiny. This was in Feb 2020, so two years ago now.

I’ve been watching this repo, but haven’t tried destiny as dependency because I’ve been waiting for it to become a bit more mature first. It looks like this repo got somewhat abandoned because the latest commit as of now is from Dec 15, 2020. So I’m curious:

• What is the future of destiny as software?

• What is the current status of the ’fractal tree structure’ idea?

I have recently joined a team that works on blockprotocol/blockprotocol and hashintel/hash repos. We don’t use the principle of fractal trees yet, but I’m thinking of persuading folks to move in this direction. Because I’m leveraging destiny-like ’fractal trees’ in all personal projects, what if I‘ve just placed myself into a bubble and am missing some superior approach? 😅 Or maybe fractal trees are still a strong concept, but we (the community) just don’t use destiny from npm? 🤔

If you are reading this issue, you must be also interested in project structuring. What would you suggest in 2022?

[michaelaflores]

@kachkaev have you found a good alternative? I haven't. Of course someone motivated could create a fork.

[AnatoleLucet]

Hey 👋 destiny colab here. I think we all lost interest in destiny for different reasons.

For me, it was the realization that there are only a few use cases where the fractal structure makes sense (at least in my opinion).
One of these few use cases is in a component based architecture but, you still need to narrow it down to sub folders. If you ran destiny on a medium-sized components/ folder it would be OK, but still less readable as a more formal approach with categories: components/common/button/..., components/features/shopping-cart-modal/..., etc.
Our minds love to categorize stuff, but we can all agree that the fractal structure lacks any kind of categorization.
By narrowing down the input scope (e.g. running destiny independently in each folder matching: components/*/*/), you can get a fractal structure and keep a readable & categorized folder structure. But by doing so, you pretty much loose the original idea behind destiny (place your files wherever, destiny handles the rest).

Another big reason was that the project kind of outgrew its original scope since it was first written by Ben.
Destiny was first written for small projects and simple use cases. When the project grain visibility, a lot more use cases started to emerge. Now destiny had to handle test files, non-vanilla imports, linked files, multiples structures, and a lot more (we were also planing on supporting more languages than just JS/TS), and all that in the same monolith, without any kind of plugin system/dependency injection.
Do not understand this in a wrong way though. I have a lot of respect and appreciation for Ben Awad's work and anyone who helped and/or contributed to this project. I just think the scope became way too broad for the current monolithic architecture.

If someone wants to fork/rewrite a new destiny, I would recommend a more plugin based architecture (parsers, opinionated formatters, etc.) with a core flexible enough to fit any language/structure based on the plugins used by the user (a bit similar to treesitter's). I don't event think this hypothetical fork/rewrite should be oriented towards fractal structures at its core, but hints toward it using a few plugins.

Anyway, @benawad I think it might be a good idea to archive this repo

[kachkaev]

If anyone is interested in the ‘fractal tree’ approach for file structuring, I gathered some thoughts on it here:
https://hash.dev/blog/file-structuring

The article enumerates a few principles and rules which are heavily inspired by Destiny. The approach is a bit more flexible and can be introduced step-by-step (more like ESLint than Prettier). I’ve been using file fractal trees for a couple of years and the approach has scaled really well with the codebases I’ve been working on. Curious to know about its flaws or blind spots!