Tab Session Manager builds two browser directories from one watcher, and ships a version number package.json never held

One watcher writes two browser directories

The watch script is a single webpack invocation against webpack.config.dev.js with the --watch flag, and its output lands in two browser specific trees.

git clone https://github.com/sienori/Tab-Session-Manager
npm install
npm run watch-dev

Chrome picks the result up at chrome://extensions, where Developer Mode has to be switched on before Load unpacked extension can point at tab-session-manager/dev/chrome. Firefox takes a different route: about:debugging, then Load Temporary Add-on against tab-session-manager/dev/firefox. One watcher, two load paths, two output directories to keep apart. The repo separates the development config, the distribution config and a shared helper into webpack.config.dev.js, webpack.config.dist.js and webpack.utils.js, and only the development path is written down end to end.

src/credentials.js is step two, before npm install

Cloning is step one of the documented setup. Step two is creating src/credentials.js by hand, before any install runs, with two exports:

export const clientId = "xxx"
export const clientSecret = "xxx"

Both values are the literal placeholder xxx in the sample, and the instructions do not say which service issues that pair or how a developer gets one. Nothing in the repository root carries them either: the root holds .github/, .vscode/, docs/, other/, src/, three webpack files, babel.config.js, config.json, crowdin.yml, BACKERS.md, LICENSE, README.md and the ignore files, and no credentials file sits among them. A clone followed by npm install without that hand written step leaves the build looking for two exports nobody supplied.

package.json says 0.0.0 while the add-on ships 7.4.0

package.json carries the name tab-session-manager and the version 0.0.0. The published add-on runs under different numbers: 7.2.1 on 2026-01-19, 7.3.0 on 2026-02-23 and 7.4.0 on 2026-07-17. So the version a user reads in a store listing does not come from the field a developer sees in the tree, and none of the three documented commands (watch-dev, build, format) writes a version anywhere. The gap between 7.3.0 and 7.4.0 is close to five months, and the last recorded push, dated 2026-08-17, landed a month after 7.4.0 shipped, so commits have arrived since that release with no matching number to point at.

engines names two exact versions and leaves no room

The engines field names node 24.13.0 and npm 11.7.0, and the setup notes repeat both as required rather than as a floor. These are exact patch numbers, not ranges, so a machine on 24.13.1 already sits outside what the project states it needs. npm treats that field as a warning unless a project makes it fatal, and no .npmrc appears in the root listing to do so. The practical effect for a contributor is that those two digits are a single point of truth with no tolerance built in, and the pair has to be copied exactly rather than approximated with whatever the machine happens to run.

React 16 and Router 5 sit beside current build tooling

The runtime dependency list reads like a 2019 generation front end living next to current build tooling. react and react-dom are 16.13.1, react-router and react-router-dom are 5.1.2, prop-types 15.7.2, react-autosuggest 10.1.0, react-highlight-words 0.16.0 and react-transition-group 4.3.0. Beside them sit moment 2.29.4, query-string 6.11.1, clone 2.1.2, url 0.11.0, lodash 4.17.21, loglevel 1.6.7, browser-info 1.2.0, browser-image-compression 1.0.14, mozlz4a 1.1.0, uuid 11.1.0 and webextension-polyfill 0.12.0. The build side is a good deal newer: webpack 5.88.2, sass 1.86.0, prettier 3.0.0 and @babel/plugin-transform-class-properties 7.25.9. Two names in the list hint at payload handling rather than interface code: mozlz4a is the only entry named after a compression format, and browser-image-compression is the only one named after images.

The Session Compressor and the privacy policy share one host

The Tools section points at a Session Compressor hosted at tab-session-manager.sienori.com/compressor/index.html, described as a tool for compressing sessions created by the add-on. No compressor source sits in the repository root listing, and nothing in that listing looks like the page itself, so the tool is something you reach by URL rather than something you build or read in this tree. The privacy policy lives on the same host, at tab-session-manager.sienori.com/privacy-policy. A saved session stands for a whole set of windows and tabs, so any page handed an exported file is holding every URL in that set at once, and the repository does not say whether the compressor works entirely inside the page or talks back to the host.

Automatic saving is stated in a sentence and explained nowhere

Automatic saving is the one behaviour the README states in a single sentence, and it is the one thing the repository never explains how to enable, tune or stop. The file covers where to fetch the add-on for Firefox, Chrome and Edge, who funds it, the compressor, translation, the development setup and a link to the privacy policy. There is no settings walkthrough, no list of what a saved session stores, and no note about where an export ends up on disk or how long it stays. Anyone who wants that behaviour shaped in a particular way has to read the source under src/ to find the switch.

Format globs skip docs/, translations go to Crowdin

Two housekeeping choices matter before a first patch. Translations are routed to a Crowdin project rather than collected through the repository, with crowdin.yml at the root holding that wiring, so a translator works in Crowdin rather than in a pull request. And the format script writes prettier across src/**/*.{js,jsx,json,scss,html,md} and *.{js,json,md}, while format:check applies the same two globs. Both stop at the top level, so files under docs/ and .github/ sit outside the check even though .prettierrc and .prettierignore are at the root. A documentation edit and an src/ edit therefore pass through different rules inside the same pull request.

Editorial conclusion

Fit for someone who wants the store build and wants to read the source before trusting it with a browser full of tabs. Before installing, open the privacy policy on the project's own host and decide what an exported session carries. Before building, expect to write src/credentials.js yourself and to match two exact toolchain versions. Nobody has documented the settings behind automatic saving, so read the code under src/ for those.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. sienori/Tab-Session-Manager on GitHub