docs(modules/nebula.gl)!: restore to glory

[charlieforward9]

Summary

• Adds docs/modules/nebula.gl/design-rfc.md preserving architectural rationale from the 4 original nebula.gl RFCs that were removed in chore: remove dead code and outdated WIP content #505
• Fixes pre-existing prettier formatting drift in 7 files that was blocking the pre-commit hook

Context

The dev-docs/RFCs/editable-layers/ directory was deleted in #505 with the message "implemented and no longer needed." While the interfaces are implemented, the RFCs contained valuable design rationale -- the "why" behind the architecture -- that was not captured anywhere in the current docs.

Key content preserved:

• Generic EditMode RFC -- why ModeHandler was replaced, the framework-agnostic design intent, module boundary rationale (edit-modes has no deck.gl dependency), and the non-geospatial extensibility goal
• Tentative Feature RFC -- the geometry type volatility problem and how separating tentative state from committed data solves it
• Multi-Geometry Editing RFC -- the unimplemented problem statement for appending to Multi* features
• react-map-gl-draw RFC -- the stateless component design, feature state machine, and why it was not ported

This is directly relevant to #496 (non-geospatial coordinate support), which references the Generic EditMode RFC by URL at the now-deleted commit.

Test plan

• Verify the new doc renders correctly in the docusaurus sidebar
• Confirm prettier formatting changes are cosmetic only (arrow function parens, JSX line wrapping)

Relates to #496

Generated with Claude Code

[ibgreen]

In the past, we have decided to not include RFCs in the docs tree since they are not updated to reflect the latest status.
Instead having a simple link in the docs to the github directory where users can find the RFCs is a good compromise.
I know you really want to reduce the number of top-level directories.

Having these in the docs folder will make them indexable by the docs search which can be confusing. I.e. even if you leave them out of the table of contents, they are still there and can be searched and opened.

[charlieforward9]

> value in keeping the old RFCs they do provide some historical design context that could help maintainers or maybe even LLMs

I was under the impression you wanted this. I understand if you prefer to have a docs/rfc/ instead. But rfc/ outside the docs/ is bloating - im trying to find better homes for rfc/'s faster - like GH discussions / issues / PRs / docs

[charlieforward9]

If you have any immediate pointers youd like to see made in editable-layers as I bring it back to nebula.gl - please chime in @georgioskarnas

It would be great to take www.nebula.gl domain into visgl

[ibgreen]

Firstly, this seems to contain both a restoration of a removed file and a bunch of code changes. Should it be split into two PRs?

Just noting that the strong push you are driving to minimize directories in the root, while well-intended and valuable, is bringing up various issues: the directories that are being removed were there to avoid some practical issues / real concerns.

On the RFC in docs folder topic:

• We have tried a number of different approaches to RFCs. Some RFCs have indeeed been raised as issues. These have the advantage that commenting on them is easier, but they do tend to get lost as time goes on.
• I can't think of any obvious solution for RFCs that makes everyone comfortable, but at least let's keep the old ones in the source tree for now.
• If you really want the RFC in docs folder, would be good if there was a way to exclude them from search, but that requires more config etc.

General comment

At this point, I think the best compromise might be to accept one extra folder in the root (perhaps called dev) and put all the stuff that is not part of the latest production builds there.

• RFCs
• wip modules
• wip examples
• ...

Mixing in outdated and half-finished files in the main directory structure will always raise concerns, some folks have very strong objections to including anything that is unfinished or confusing.

[charlieforward9]

To echo what I proposed during a previous call:

Keeping wip work as open PR/branches instead of in master branch

I have reduced the amount of PR's from ~60 to ~33, with a majority of them being your graph-layer changes.

If we kept all the wip as PR's - and kept the active PR's lean - it would give anyone visiting an idea of what truly is in progress vs what is publicly available via npm or the examples.

You did mention that navigating the git tree can become a hassle - which is why I am prioritizing keeping a clean PR list and attending to new ones as quickly - and agentically - as I can.