Deprecate `@require` metadata

[ACTCD]

• Implement getResourceURL, getResourceText, @resource #224

Revisiting this feature, I think we should deprecate it instead of implementing it.

The starting point for considering this issue has never been to maximize compatibility with third-party user scripts. We pay more attention to security, efficiency, ease of use, and maintainability.

User scripts are often a more lightweight snippet of code compared to the browser extension itself, rather than a complete replacement for the full extension interface.

In a browser extension, we can put any resource in the extension package and get it easily through the runtime.getURL() API. But for user script resources, we cannot do this.

Implementing similar APIs in user scripts requires very complex processes and at the expense of efficiency and maintainability, without providing significant advantages. Generally speaking:

• We need to parse those resources from user script metadata
• We need to download from the network and manage cache status sync to user scripts
• We need to convert it into a passable message (e.g. base64) and pass it from native to extension
• Then we need to pass it from the background script to the content script
• Finally we return it to the user script through the GM API

If it always needs to be converted to string (e.g. base64), why don't we embed it into user scripts from the beginning, but use complex separate resource management and delivery methods? It just adds complexity without saving any resources or improve performance.

And we now have a lot of excellent bundle tools that allow us to package complex projects into single user script files.

On the other hand. By leveraging native JS API fetch or GM.xmlHttpRequest, we could already easily load any resource from the network and they better handle binary resources.

Implementing an API represents our intention to maintain and encourage people to use it continuously, but at this point I can't see both, and in fact I'm more encouraging people to script in a simpler, native way.

Compared to many apps becoming increasingly large and bloated, I have been trying to do "subtract" in this extension from methods that are difficult to maintain and no longer recommended. And I delved into almost every detail to arrive at those decisions.

I am also a user and author of user scripts myself, so I wish to keep this extension a lightweight, simple, efficient, secure and maintainable user script manager, and I hope we could maintain some advantages and continually improve those still insufficient aspects.

Originally posted by @ACTCD in #224

For the same reason that we abandoned the implementation of @resource, I think we should also plan to deprecate @require to encourage people to use a more native and universal modern approach.

• Bundle them into end user scripts via packaging tools
• Use JS Native Dynamic import API import()

We hope to eventually strip these logic out of the core injection process, but in order to maintain compatibility with current scripts, we may provide internal or external alternatives.

[ACTCD]

Take jQuery for example:

// ==UserScript==
// @name           Legacy `@require`
// @match          *://example.com/*
// @require        https://code.jquery.com/jquery-3.7.1.js
// ==/UserScript==

(function () {
	$("h1").css("color", "red");
})();

The changes needed are just:

// ==UserScript==
// @name           Dynamic `import()`
// @match          *://example.com/*
// ==/UserScript==

(async function () {
	await import("https://code.jquery.com/jquery-3.7.1.js");
	$("h1").css("color", "red");
})();

And dynamic import supports conditional import, and a third-party module can be imported only when the user turns on a certain setting or, for example, when an element is detected. It doesn't need to import and run all of the modules at the beginning, and the browser will cache and manage the resource.

You can also import json modules like:

(async function () {
	const { default: data } = await import("data.json", {
		with: { type: "json" },
	});
	console.debug(data);
})();

[ACTCD]

Reserved

[F9y4ng]

Do you completely ignore the situation that CSP prevents calling remote JS?

[ACTCD]

@F9y4ng CSP only affects the page context rather than the content script context, in other words it can also block the entire user script rather than just the required libs.

In addition, developers can always bundle scripts in advance. And by using bundling tools, it allows developers to use the benefits of standard import syntax and intelligence or lint etc., which ultimately improves the development experience and maintainability.

[F9y4ng]

This completely ignoring compatibility with other script management will only cause it to lose users.

And how many developers will develop Userscripts support only scripts? This maverick approach will only make developers more cautious about recommending this script manager. I think I won't.

[ACTCD]

Just to state again:

• This will NOT be immediately unavailable nor will it be removed anytime soon

• And we will try to provide internal or external alternatives to remain compatible

• It will simply be marked as deprecated and no longer recommended

Regarding compatibility, we have never achieved 100% compatibility, just as this is not achieved between products themselves. Like here you could see:

• More compatible .user.js URL support #822 (comment)

@F9y4ng Thanks for the concerns you raised, but I don't see a strong reason to prevent the proposal from happening, and as I mentioned in the original text, we want to provide a simpler, efficient, secure and maintainable extension that ultimately offers everyone a better experience.

[F9y4ng]

• This will NOT be immediately unavailable nor will it be removed anytime soon
• And we will try to provide internal or external alternatives to remain compatible
• It will simply be marked as deprecated and no longer recommended

v4.8.2 is no longer able to fetch @requeir resources, but the same script in Tampermonkey is able to fetch @require resources correctly.

[ACTCD]

v4.8.2 is no longer able to fetch @requeir resources, but the same script in Tampermonkey is able to fetch @require resources correctly.

4.x.x did not make any changes regarding this, and it also hasn’t changed in 5.0 yet.

If you could provide a detailed reproduction report, please submit a new issue.

[F9y4ng]

4.x.x did not make any changes regarding this, and it also hasn’t changed in 5.0 yet.

If you could provide a detailed reproduction report, please submit a new issue.

Ah, I directly downgraded from v5.0BETA to install v4.8.2. It may be cache or other problems that caused the require resource to be abnormal. I uninstalled and reinstalled v4.8.2 and it returned to normal. This is probably a misunderstanding, thank you for your reply.