Changing Chrome User Data location

By default, Google Chrome on Windows stores all its data in:

C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data

This folder seems to top around 2.5 GB, as I tested both in Chrome and Brave.

When digging the portable version of Brave, I found that it uses the --user-data-dir command line switch to store the data somewhere else – that’s the whole point of being portable.

This command line switch, obviously, belongs to Chromium, and so to all its derivative browsers, like Chrome itself. Therefore, you can move Chrome’s User Data folder to any location. After moving the folder itself, you just have to pass the new location via the --user-data-dir command line switch, as explained in Chromium Docs:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=D:\Stuff\ChromeUserData

This finding is also useful because it shows that the whole User Data folder can ba copied to a different computer.

I found a possible Chromium bug, however, when moving User Data to my D:\ drive. When a notification pops-up, clicking it will open another Chrome window, and this new window will point to the original User Data location. Which means native notifications are unusable.

Install PKCS#11 in Brave, Linux

As Chrome’s adoption of Manifest V3 approaches, I’ve been trying Brave more and more, even in my Android. Using it for work had me in trouble though, since unlike Firefox, it has no native support to PKCS#11 USB tokens.

After trying a few things, I gave up. But a few minutes ago I stumbled upon a website which I’ve seen before, probably when setting up Chrome, and to my surprise it worked for my Linux Mint. He uses the same SafeNet eToken 5110 I’ve got here.

modutil -dbdir sql:.pki/nssdb/ -add "eToken" -libfile /usr/lib/libeTPkcs11.so

I don’t know if it matters, but I ran the command above before installing Brave itself.

Cleaning Windows temp folder

As my SSD gets more and more stuffed, I’m searching for ways to remove the cruft from it. It’s a Windows 10 installation from 2018, which I have a feeling that it needs a fresh formatted install. But since I cannot afford that now, I just keep going.

Cleaning the temp folder manually is a cumbersome chore and also takes a lot of time. The batch script below, in the other hand, deletes all the files instantly:

@echo off

echo Cleaning temp...
cd %temp%
rmdir . /s /q

pause

A double click on the clean.bat file now can be done at any time, in no time.

Pinia sucks

Today I completely wiped away Pinia from a large Vue codebase at work. It was an immense effort, but I’m so pissed I didn’t mind working overtime.

The main reason to use Pinia is that you can inspect the state in DevTools – an idea taken from React –, but guess what. The extension only exists for Chrome now, and the current old Firefox version is broken. It looks like a project driven by amateurs, just like the horrible VSCode extension. And I’m not alone on this.

For the global stores, I’m simple using a reactive object, with functions and computed values inside – that’s what Pinia does anyway. I found this by digging into its source code. I also found that a computed inside a reactive makes the .value unnecessary, which is a merit of Vue’s reactivity system, which I still believe to be the best out there.

const state = reactive({
	loading: false,
	name: '',

	foo: computed(() => state.name + '.'),

	doAction(): {
		console.info('Hello');
	},
});

I really regret choosing Vue back in the day for this project. I should’ve choosen good ol’ React, because despite its flaws, it’s dependable.

Lean Pinia stores

Three years ago – time files – I wrote a hack to remove the boilerplate fields from a Pinia store. It worked well.

This morning, writing work stuff, I wrote a lightweight wrapper to Pinia’s defineStore, with the primary intent to remove the manual string ID which needs to be given. After the initial TypeScript brouhaha, it went so well that I was able to fully integrate the boilerplate strip with Omit, which is a solution even less intrusive than the one I wroten 3 years ago.

import {_ActionsTree, _GettersTree, defineStore, DefineStoreOptions, Pinia, StateTree, Store, StoreGeneric} from 'pinia';

let nStore = 0;

type LeanStoreDef<Id extends string = string, S extends StateTree = StateTree, G = _GettersTree<S>, A = _ActionsTree> = {
	(pinia?: Pinia | null | undefined, hot?: StoreGeneric): Omit<Store<Id, S, G, A>,
		'$id' | '$dispose' | '$onAction' | '$patch' | '$reset' | '$state' | '$subscribe' | '_customProperties'>;
	$id: Id;
}

// eslint-disable-next-line @typescript-eslint/no-empty-object-type
export function newStore<Id extends string, S extends StateTree = {}, G extends _GettersTree<S> = {}, A = {}>(
	options: Omit<DefineStoreOptions<Id, S, G, A>, 'id'>,
): LeanStoreDef<Id, S, G, A> {
	return defineStore(('siorg-store-' + ++nStore) as Id, options);
}

Usage is just exactly what I had in mind:

const useNames = newStore({
	state: () => ({
		names: [] as string[],
	}),
	getters: {
		count: state => state.names.length,
	},
	actions: {
		add(name: string): void {
			this.names.push(name);
		},
	},
});