Codebase cleanup, modernization, and build process questions

Hello,

I'd like to open a discussion regarding the Violentmonkey codebase. In its current state, there are several areas that need cleanup and modernization.

For example (what am I looking at?):

violentmonkey/src/background/utils/script.js

Lines 190 to 226 in 4d47724

    
           function inferScriptHome(script) { 
        
             let u = script.custom.lastInstallURL; 
        
             if (u) { 
        
               u = u.split('/', 6); 
        
               switch (u[2]) { 
        
               case 'update.greasyfork.org': 
        
               case 'update.sleazyfork.org': 
        
                 u[2] = u[2].slice(7); 
        
                 // fallthrough 
        
               case 'greasyfork.org': 
        
               case 'sleazyfork.org': 
        
                 if (u[3] !== 'scripts') u.splice(3, 1); 
        
                 break; 
        
               case 'raw.githubusercontent.com': 
        
                 u[2] = 'github.com'; 
        
                 break; 
        
               case 'github.com': 
        
                 break; 
        
               case 'openuserjs.org': 
        
                 u[3] = 'scripts'; 
        
                 u[4] = u[4].replace(/(\.min)?\.user\.js$/, ''); 
        
                 break; 
        
               default: 
        
                 u = false; 
        
               } 
        
               if (u) { 
        
                 u.length = 5; // scheme + 1 + host + group + name 
        
                 u = u.join('/'); 
        
               } 
        
             } 
        
             if (!u) { 
        
               u = script.meta.namespace; 
        
               u = /^https?:\/\/(?!tampermonkey\.net\/)/.test(u) 
        
                 && getFullUrl(u).replace(/^https?(:\/\/userscripts)(\.org\/users\/\w)/, 'https$1-mirror$2'); 
        
             } 
        
             return u; 
        
           }

I also came across syntax like the following, and I'm not entirely sure whether this is standard ECMAScript or something transformed during the build process:

const meta = metaTypes::mapEntry(value => value.default());

We could start migrating parts of the code to TypeScript to improve maintainability. It would also make it easier to contribute.

It would also be good to add documentation or improve the inline JSDoc comments to better explain the code.

It might be worth revisiting parts of the build setup. For instance, I'm curious about the reason behind storing the extension manifest as a manifest.yaml file and then converting it into manifest.json during the build process.

Do contributors/maintainers think this is something worth investing time into?

@gera2ld

For example (what am I looking at?):

Looks like code that I wrote and that violates a few best practices. Please be more specific if it's something else.

metaTypes::mapEntry

This is a binding operator, which was abandoned by JS committee, but we use it for guarding against prototype poisoning. Without this syntax implemented as a Babel transform we would have to write safeCall(mapEntry, metaTypes, value => value.default()) which is barely readable as it is, not to mention nested calls. This is not supported in TypeScript, so I don't think these scripts should be converted until an alternative operator is standardized or TS provides a way to extend its syntax via plugins.

TypeScript to improve maintainability. It would also make it easier to contribute.

This is subjective and depends on who is contributing. The author @gera2ld knows and uses TS, but evidently isn't particularly interested. I use TS mostly to define types and personally I think TS might make sense for vue templates but then again maybe we should switch to something else from vue so the effort would be wasted.

It would also be good to add documentation or improve the inline JSDoc comments to better explain the code.

This, along with TS migration, is not a pressing issue until the MV3 version is made, which would arguably require conditional compilation and a lot of changes.

manifest as a manifest.yaml file and then converting it

I guess @gera2ld likes YAML because it's easier to read and maintain and it's already used for translations.
I don't have a preference.

Do contributors/maintainers think this is something worth investing time into?

TLDR, not at this point.

Navigation Menu

Repository navigation

Codebase cleanup, modernization, and build process questions #2514

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	function inferScriptHome(script) {
	let u = script.custom.lastInstallURL;
	if (u) {
	u = u.split('/', 6);
	switch (u[2]) {
	case 'update.greasyfork.org':
	case 'update.sleazyfork.org':
	u[2] = u[2].slice(7);
	// fallthrough
	case 'greasyfork.org':
	case 'sleazyfork.org':
	if (u[3] !== 'scripts') u.splice(3, 1);
	break;
	case 'raw.githubusercontent.com':
	u[2] = 'github.com';
	break;
	case 'github.com':
	break;
	case 'openuserjs.org':
	u[3] = 'scripts';
	u[4] = u[4].replace(/(\.min)?\.user\.js$/, '');
	break;
	default:
	u = false;
	}
	if (u) {
	u.length = 5; // scheme + 1 + host + group + name
	u = u.join('/');
	}
	}
	if (!u) {
	u = script.meta.namespace;
	u = /^https?:\/\/(?!tampermonkey\.net\/)/.test(u)
	&& getFullUrl(u).replace(/^https?(:\/\/userscripts)(\.org\/users\/\w)/, 'https$1-mirror$2');
	}
	return u;
	}

Codebase cleanup, modernization, and build process questions #2514

Description

Activity

tophf commented on May 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions