V2EX Polish: a browser extension that rebuilds the V2EX interface

What V2EX Polish changes and who it is for

V2EX Polish is a browser extension for V2EX, a community discussion site. The repository description calls it a professional V2EX browser extension that collects many practical features and reshapes your browsing experience, and the README calls it a lightweight plugin designed for V2EX users with a rich set of extension features that make the original pages look new.

The feature list is long and, unusually, specific about the mechanics. The interface is redesigned. Comment replies under a topic are shown in a nested hierarchy so you can follow conversations. Popular replies are filtered out automatically so the highly rated ones surface first. The reply box can insert emoji. Long replies are folded automatically with a one-click expand. A built-in topic list gives you the hottest and newest topics and message notifications without opening a page. Reply actions include previewing a reply, converting text to Base64, and uploading images.

The extended list adds automatic daily check-in rewards, user tags for marking people, user info cards, following the system light and dark theme, decoding any Base64 content on a page, preloading multiple pages of replies to render nesting properly, horizontal reading of topic content, a read-later list, previewing a topic from the list, generating a share image for a topic, backing up personal configuration across devices, and jumping to the reply section after paging.

The target user is a regular V2EX reader, and the pitch is explicitly about competing with the other V2EX enhancements. The README says that although many scripts and extensions for v2ex.com already exist, their quality varies and most have stopped being updated, and the project's goal is to provide a more complete extension and keep it updated.

One line in the README lists a V2EX topic about the extension being unexpectedly removed from the Chrome Web Store, so the distribution channel has had its own history.

Four ways to install, with different feature sets

The extension is available in four forms, and the differences between them are documented rather than glossed over.

Chrome, Edge and Arc users install it from the Chrome Web Store. Firefox users download it from addons.mozilla.org. Safari users are pointed to an installation guide in the repository at `website/src/content/docs/use-in-safari.md`. And there is a userscript on Greasy Fork, which the README marks as supporting only some features.

The userscript gap is spelled out in the FAQ. The userscript does not support all the personalisation settings, the right-click function menu, or the user tag settings. The browser extension supports everything and has been tested more thoroughly, and the README recommends the extension for the best experience.

The size argument is answered with a number: the installed size is under 0.2 MB, and the project says it pays attention to extension size and performance in order to reduce resource usage. That is a small number for an extension that rewrites a site's interface, and it is the sort of figure a reader should be able to verify by looking at the store listing before installing something that runs on every page of a logged-in site.

The README also carries a prominent warning that using other similar scripts or extensions may cause conflicts, and that if page content looks wrong you should disable other extensions to isolate the problem. The FAQ repeats it in the form of a question about broken content and odd styling, and the answer is that other V2EX-related extensions are the likely cause.

Nested replies and the floor number problem

The nesting feature is the one the project is most candid about, because it is the one it cannot make fully correct.

The FAQ asks why some nested reply floor numbers are wrong, and the answer explains the underlying limitation of the source data. V2EX's original replies do not record which floor was being replied to, so the extension can only look for the most recent reply by the user being replied to and embed the reply after that one. The method cannot guarantee that it identifies the floor the user actually meant to reply to.

That is a data model problem, not a bug, and no amount of work in the extension can fix it without a change on V2EX's side. It does mean the nested view is a best-effort reconstruction, and a user reading a thread may see a reply attached to the wrong parent.

Two related features sit alongside it. Preloading multiple pages of replies is what makes the nesting render properly, because the parent of a reply may be on an earlier page. And hiding the names of mentioned users in replies is listed as a feature, so a reply that quotes a person does not display the name.

The rest of the reply workflow is fairly complete: you can preview a reply before sending, upload images directly in the reply, and insert popular emoji. The image upload flow is shown in the README's example gallery as a short animation, which suggests it happens inline rather than through a separate upload page.

What the personal access token is for, and what it is not

The FAQ has a question about why a personal access token, or PAT, needs to be set, and the answer is careful to say that it is not required.

The token is only needed if you want features such as topic content preview and fetching message notifications, because those features call the V2EX open API. If you do not have one, the README points to the page in V2EX's settings where you can create it.

So the default install is a purely local enhancement: a restyled interface, nested replies, folded long posts, emoji, a read-later list and the rest of the client-side conveniences work without giving the extension any credential. Only the two features that need data from the site require the token, and the token is scoped to what the V2EX API exposes.

That distinction matters for a reader deciding what to install. The extension reads the page you are already logged into in order to render it differently, and it needs a credential only if you ask it to fetch data the page does not already contain.

Backing up personal configuration is another feature, described as supporting synchronisation across devices. The README does not say where that backup is stored or whether it is encrypted, so the storage location is worth checking in the settings before you rely on it for something you would not want to lose.

How the build is put together, from package.json

The project is TypeScript, built with Bun as the script runner and pnpm as the package manager, with a `pnpm-lock.yaml` in the tree.

The development workflow is a set of parallel processes. The `dev` script runs `build:manifest`, a watcher and `run:chrome` together. The `run:chrome` script invokes `web-ext run` targeting chromium against the `./extension` directory, with a dedicated chrome profile that is created if missing and keeps its changes, and it starts the browser at the V2EX home page:

"run:chrome": "web-ext run -t chromium --source-dir ./extension --chromium-profile ./chrome-profile --profile-create-if-missing --keep-profile-changes --start-url https://www.v2ex.com/"

The firefox script is the same idea without the chromium profile, and there is a separate `dev:firefox` script for it.

The build is layered, and the layering mirrors the four distribution targets. `build:all` runs `build:manifest`, `build:style`, `build:ext` and `build:userscript` in parallel. The manifest is generated by a script, styles are compiled with sass into `extension/css` as compressed with no source map, the extension itself is bundled with tsup, and the userscript is a separate tsup build from `src/user-scripts/index.ts` that is deliberately not minified, because a userscript is read by humans. The final `build` script then packages a Chrome build and a Firefox build with `web-ext build`.

The dependency list is short: `@floating-ui/dom` for positioning, `lucide` for icons, and `webext-patterns` for matching extension URL patterns. There is no framework in the dependency list, which is consistent with the size claim.

Linting is split four ways, and the TypeScript check is a type check rather than a linter: `tsc --noEmit --skipLibCheck`. ESLint handles JavaScript and TypeScript, Stylelint handles CSS and SCSS, and Prettier handles Markdown and JSON. The repository also has `.eslintrc.cjs`, `.stylelintrc.cjs` and `.prettierrc.cjs` configuration files, and a `website/` directory holding the documentation site, whose `src/content/docs` folder contains the Safari guide.

No open source licence, and an uncertain release trail

The licence field of `package.json` is `UNLICENSED`, and the GitHub metadata records the licence as unknown. The package is also marked private, with a version of 0.1.0 in the manifest while the distributed extension versions are in the 1.x range.

This is the most consequential thing about the project for a technical decision. The source is visible, but there is no open source licence granting you the right to use, modify or redistribute it, and the `package.json` explicitly says unlicensed. A reader who wants to fork it, vendor a change, or build the userscript from source for their own organisation is in a different legal position than with an MIT or Apache licensed project, and no `LICENSE` file appears among the top level repository entries.

The release history is thin as well. The recent releases are v1.11.0 from 2024-09-30, v1.10.0 from 2024-05-12 and v1.9.0 from 2024-03-10. The last push to the repository was on 2026-04-15 and the repository is not archived, so development continues on the default branch, which is main, but there is no newer tag than the one from 2024.

That gap between the tag and the head means anyone installing from the store and anyone building from the branch may be running different code, and the store listing is the version most people will get. The project's own linked V2EX topics include monthly update notes, which suggests regular releases that the GitHub tag list does not fully reflect.

There is a `CONTRIBUTING.md` in the `.github` directory for code contributions, and a donation link to `v2p.app/support` alongside a Telegram group and a GitHub discussions board for feedback.

Editorial conclusion

V2EX Polish suits V2EX users who want a faster reading and replying experience and who accept installing a third-party extension that reads and rewrites the pages of a site they log into. It does not suit an organisation that requires its extensions to be open source and auditable, because `package.json` declares the package private and UNLICENSED, and it does not suit anyone who needs a published, dated release, since the newest tag is v1.11.0 from 2024-09-30 while the last push was on 2026-04-15. Before installing, decide whether the extension or the userscript is right for you, because the userscript drops the personalisation settings, the right-click menu and user tags, set a personal access token only if you want topic previews and notifications, and turn off any other V2EX extensions to rule out a conflict.

Frequently asked questions

Official sources

1. coolpace/V2EX_Polish on GitHub
2. Issues
3. Project website
4. README
5. Releases