Advanced Tables for Obsidian: the table logic lives in another package, and the plugin warns it can delete note data

The table logic sits in another package, pinned at 3.11.0

The project has exactly one runtime dependency: `@tgrosinger/md-advanced-tables` at version 3.11.0, written without a range so a build cannot drift on its own. Everything the feature list advertises sits on top of that one library, spreadsheet formulas, sorting rows by a chosen column, adding, removing and moving rows and columns, CSV export. What this repository holds in `src/` is the Obsidian-facing half: key handling, the command palette entries, the table controls sidebar that Ctrl+Shift+D opens, and the stylesheet beside it. Two consequences follow for anyone reading the source. A formula is not implemented here, so a defect in formula handling is fixed in a different repository and reaches users only when that pinned version changes. And because the pin is exact, a fix already published upstream is not picked up by a fresh install until someone edits this file.

The Obsidian API is pinned to one commit of a tarball

One dev dependency is not a version number at all. `obsidian` is a tarball URL pointing at an archive of the obsidianmd obsidian-api repository at a single fixed commit hash. The plugin therefore compiles against one frozen snapshot of the Obsidian API, and taking anything added to that API later means editing the hash inside the URL. The rest of the block mixes two pinning styles side by side: typescript is fixed at 5.3.3, eslint at 8.57.1, tslib at 2.6.2, while esbuild and the import-sorting eslint plugin carry caret ranges and float within their major version. That eslint pin is also why the root still carries `.eslintrc.js` and `.eslintignore`, the older configuration layout, rather than the flat config that newer eslint majors read.

main.js is the declared entry point and is not in the tree

`package.json` names `main.js` as the entry point, and no file by that name appears among the repository's top-level entries, which hold `src/`, `styles.css`, `esbuild.config.mjs`, `tsconfig.json` and the lint and format configuration. That is ordinary for a plugin written in TypeScript: `main.js` is emitted by the build, and Obsidian loads the built file rather than the sources. The build script runs a type check and then the bundler in production mode, and the dev script runs the same bundler without that argument, so a contributor gets a working `main.js` locally without passing the type gate:

tsc -noEmit -skipLibCheck && node esbuild.config.mjs production

Note that the flags use a single dash, which the TypeScript compiler accepts, and that `-noEmit` means tsc type checks without writing anything. Every line of output comes from esbuild. The tree also carries a `resources` directory, a `docs` directory and a `.devcontainer` directory, so a contributor can work inside a prepared container rather than matching a local toolchain by hand, and `tsconfig.json` decides whether that type check passes at all.

Formatting and lint never reach the documentation it ships

The prettier script targets a glob of files under `src` for ts, tsx, json, html and css. The eslint script runs over the repository with `--ext .ts,.tsx` and `--fix`, so it rewrites files in place as it checks them. Neither reaches the `docs` directory or the README, even though the tree ships a docs directory and the project's own documentation sends readers there for the formula reference. A `.prettierrc` exists for editor defaults, but nothing on the command line applies it outside `src`. The practical effect is that the page most readers are directed to, the one that has to explain formulas precisely, is hand formatted and reviewed by eye, while the TypeScript is held to a mechanical standard. The prose is where this project is most likely to drift out of date.

A pnpm workspace file for a one-package repository

The project identifies its package manager with a full identity string, pnpm at 11.1.1 followed by a sha512 integrity hash, and it ships both a lockfile and a workspace file. The workspace file is the part worth reading twice. A pnpm workspace file is where you declare a set of packages that should be built and locked together, and this repository has one package manifest and one public dependency, so the workspace covers exactly the package it already had. Nothing breaks because of it, and nothing is gained either. It is a leftover of a layout this project does not use, and it is one more file a new contributor has to read before touching the build. Alongside it sits a lockfile, which is the file that makes installs repeatable: the exact pins in `package.json` say which versions are acceptable, and the lockfile records the resolved tree. The same pattern shows up in the release cadence, with two releases published fifteen minutes apart on 2026-05-13, and with 111 open issues against 2,614 stars on a plugin this small.

The Demo heading is empty and the help page lives in docs

The documentation's Demo section is followed straight away by the next heading, so the part that would show the plugin working carries nothing at all. What a reader gets instead is a hotkey table mapping Tab to the next cell, Shift+Tab to the previous cell, Enter to the next row, and Ctrl+Shift+D to the table controls sidebar, plus a link to the help docs for formulas. Creating a table is typed rather than clicked: put down a single pipe character, type the first heading, press Tab, and keep going. The command palette holds many more commands than the four in the table, and the documentation's own instruction is to scroll to find them. The feature list itself sends one of its bullets to a help page anchor about using formulas in markdown tables, which is an admission that formulas do not fit inside a table cell of documentation. So the first thing a new user meets is thinner than the feature list at the top of the page, and the gap between the two is what the help docs exist to close.

Mobile loses Tab and Enter, so the toolbar carries navigation

The mobile note states the limit plainly: using Enter and Tab to navigate a table will not work, so navigation has to come from somewhere else. The Next Cell and Next Row commands can be added to the mobile toolbar, or the buttons in the sidebar can be used instead. That is the whole mobile story, and it is worth reading before enabling the plugin on a phone, because the keyboard handling is what defines the experience everywhere else. Auto formatting, formulas, row and column manipulation, alignment, sorting and CSV export do not depend on the keys, so a phone user who configures the two toolbar commands gets most of the plugin. A phone user who does not gets a table editor that cannot move the cursor between cells, which is the one operation the plugin exists to make easy.

Two releases fifteen minutes apart, and a warning about deleted data

The notes at the end of the documentation are the most important paragraph in the project. They call the plugin experimental, warn that it may be unstable, say outright that bugs may delete data in the current note, and ask readers to make backups. That warning belongs to a plugin whose entire job is rewriting the table under the cursor as you type, including auto formatting, so a mistake in that rewrite path touches the note itself rather than a cache. Version bookkeeping is otherwise tidy: `package.json` carries 0.23.2, matching the newest tag, with 0.23.1 published fifteen minutes earlier the same day and 0.22.2 three weeks earlier on 2026-04-24. Installation means turning safe mode off in Obsidian's third-party plugin settings and installing from the community plugin browser, with a documented floor of Obsidian v0.9.8. There is no paid tier to fall back on: the plugin is given away, and support is asked for through three donation links instead.

Editorial conclusion

This plugin earns a place in a vault where tables are typed often, and its mechanics are worth understanding before you enable it. Three facts decide the rest. All table logic, formulas and sorting included, sits in a separate package pinned at an exact version, so improvements arrive when someone edits that pin rather than when you update the plugin. The Obsidian API is pinned to one commit hash, which is why a plugin release is about compatibility as much as features. And the project itself warns of instability and possible data loss in the current note, so treat enabling it as a change to make with backups and a version you can roll back to. Skip it on mobile unless you intend to add the navigation commands to the toolbar, since Tab and Enter do nothing there.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tgrosinger/advanced-tables-obsidian on GitHub