LinuxDo Scripts: a browser extension for the LinuxDo forum, now maintained by pull request

What LinuxDo Scripts changes on the LinuxDo forum

LinuxDo Scripts is a browser extension, not a userscript manager collection, and every feature is scoped to the LinuxDo forum. The README describes it as an extension that improves the browsing and interaction experience on that site, with features running from basic interface adjustments to AI assistance. It also states the extension is compatible with idcflare.com. The repository description adds that it is listed on the Chrome Web Store and the Firefox store.

The audience is narrow on purpose. This is for people who already spend time on LinuxDo and want the forum to behave differently: the README lists a favourites enhancement and a post-sharing feature among the screenshots, and the top-level repository contains a docs/ directory and a plugin/ directory for the parts that ship separately. If you never open LinuxDo, nothing here applies to you. There is no generic web-improvement layer to reuse elsewhere.

How the extension is built: WXT, Vue 3 and entrypoints

The build system is WXT, visible in wxt.config.ts and in the package.json scripts, where dev maps to wxt and build maps to wxt build. WXT handles manifest generation for MV3 and for Firefox, which is why the same source produces different bundles. The UI layer is Vue 3 with Arco Design components: package.json lists vue ^3.5.12, @arco-design/web-vue, @arco-design/web-vue's theme package @arco-themes/vue-indigo-sky, and unplugin-vue-components for on-demand component registration. The components.d.ts file at the repository root is the generated type file that unplugin-vue-components maintains.

Runtime dependencies hint at what the features do. dompurify and marked suggest HTML rendering and sanitising, html2canvas suggests screenshot or image capture, pangu handles spacing between Chinese and Latin characters, and webdav points at remote storage for settings or data. webext-dynamic-content-scripts and webext-permission-toggle deal with injecting content scripts into pages after install and letting the user toggle host permissions, which matters because an extension that only activates on specific forums should not hold broad permissions up front.

The layout is split between entrypoints/ for extension entry points (background, content scripts, popup) and plugin/ for feature modules. The README's development rules say each feature should be an independent component to avoid conflicts, and that new features must update the documentation. That rule is the closest thing to an architecture statement in the README, and it is a convention rather than something the build enforces.

Installing LinuxDo Scripts from a store or from source

For normal use the README points at store listings. Chrome, Edge, Arc and Brave users are directed to the Chrome Web Store entry with the id fbgblmjbeebanackldpbmpacppflgmlj, Firefox users to the Firefox Addons listing, and users who cannot reach those stores to the Crx store mirror. The README's install steps are: click the matching link, click add to browser, confirm the permissions, then visit linux.do.

Building from source is a different path and the README states Node.js v22.12.0 as the requirement. Clone the repository, install, and start the dev server:

git clone https://github.com/anghunk/linuxdo-scripts.git
cd linuxdo-scripts
npm install
npm run dev

npm install triggers the postinstall hook, which runs wxt prepare. For a production bundle the script is npm run build, and package.json also defines build:firefox as wxt build -b firefox, plus zip and zip:firefox for packaging. The publish script chains the build, both zips, and a Python step, py scripts/build.py.

To load the development build, the README says to open chrome://extensions/ in Chrome or about:addons in Firefox, enable developer mode, choose load unpacked, and select the .output/chrome-mv3 folder in the project root. That folder is produced by the build, so it will not exist before you run npm run dev or npm run build. A first real check is to open linux.do with the extension loaded and confirm the injected UI appears; the README does not document a diagnostics page, so the browser's own extension error console is where failures surface.

The maintenance status is the first thing to read

The README carries an explicit maintenance note. It states that because the author's personal capacity is limited, the project has stopped active maintenance and will no longer handle new feature requests or feedback, with historical issues migrated to Discussions. It then invites two things instead: direct pull requests, which will be reviewed and merged if they check out, and forks under Apache License 2.0.

That note sits above the project introduction, so it is not buried. It changes what the release history means. The last push to the repository was on 2026-09-19, and the most recent release listed is 1.5.35 from 2026-09-12. Before that, 1.5.34 is dated 2026-04-07 and 1.5.33 is dated 2026-03-20. The gap between 1.5.34 and 1.5.35 is five months, which is consistent with a maintainer who is no longer working on the project continuously. Recent commits do not contradict the note; they are the tail of work that was already in progress.

The practical reading: treat the code as frozen unless someone sends a patch. The extension will keep working as long as the forum's markup does not change underneath it, and the README does not describe any compatibility contract or automated test that would catch a breakage.

Where LinuxDo Scripts is the wrong choice

The extension is tied to one site. If LinuxDo changes its DOM, the injected components in plugin/ and entrypoints/ can stop matching, and the README offers no fallback mode or compatibility layer. There is no versioned API between the extension and the forum, so a redesign on the forum side is a breakage you have to diagnose yourself.

The maintenance note is the second constraint. If you need a fix merged on a schedule, nobody is on the other end of the issue tracker by design; the README explicitly says new feedback will not be handled. A pull request may be merged, but the README gives no review timeline. For a team that wants a supported dependency, an extension whose upstream says it has stopped active maintenance is a poor fit regardless of how well it works today.

There is also a scope mismatch worth stating plainly. The README describes AI-assisted features, and the repository ships an .env.example with an OPENAI_URL, API_KEY and MODEL. That file is aimed at a README translation script, not at the extension's runtime, but it shows the project expects you to bring your own API credentials for anything model-backed. If you are not willing to hold an API key for a forum extension, parts of the feature set are not for you.

How it compares to a plain userscript manager

The obvious alternative is running forum tweaks as userscripts under Tampermonkey or Violentmonkey. The difference is in packaging and review. A userscript is a text file you paste into a manager, editable in place, and it updates from wherever it is hosted. LinuxDo Scripts is a compiled extension: WXT produces manifest-driven bundles, Vue components are compiled, and distribution goes through the Chrome Web Store and Firefox Addons, which means store review for each release and a permission model the user approves once.

That trade buys structure. The README's development rules assume a component per feature, TypeScript with vue-tsc --noEmit as the compile check, and Prettier via .prettierrc. A userscript collection usually has none of that. It costs agility: changing one line means running the build and republishing, and the store listings are the only install path the README documents for end users.

For a single tweak, a userscript is less machinery. For a set of features that share UI components, settings storage and permission handling, the extension layout is the more honest structure, and the Apache-2.0 licence means a fork can be published under the same terms.

Licence, forks and what upgrading costs

The project is Apache License 2.0, and the README summarises the terms: you can use, copy, modify and distribute the software, use it commercially, and relicense under the conditions of the licence, provided you keep the original copyright notice and mark your modifications. That is a permissive arrangement and it is what makes the fork invitation in the maintenance note practical rather than rhetorical. If you fork, the README asks you to continue under the same licence. This is a description of the repository's own statement, not legal advice; read LICENSE before you redistribute.

Upgrade cost depends on how you installed it. Through a store, updates arrive when a new version is published, and the release history shows that cadence is now irregular: 1.5.33 in March 2026, 1.5.34 in April 2026, then 1.5.35 in September 2026. Through a source build, you own the whole loop, including npm install, npm run dev or npm run build, and reloading the unpacked extension from .output/chrome-mv3 after each change. There is no migration guide in the README for settings carried between versions, and the webdav dependency suggests settings can live remotely, which is something to check in the docs before you rely on a local profile.

Editorial conclusion

Adopt LinuxDo Scripts if you already read the LinuxDo forum daily and want its interface tweaks without writing them yourself, and accept that the README says the author has stopped active maintenance. Do not adopt it if you need a vendor-backed extension with a support commitment, or if you are not a LinuxDo user, since the features target that site and its idcflare.com mirror. Before relying on it, read the Apache-2.0 LICENSE, check the version-log page for the 1.5.35 release, and confirm the .output/chrome-mv3 load path if you plan to build from source.

Frequently asked questions

Official sources

1. anghunk/linuxdo-scripts on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases