violentmonkey: Metadata parser cannot recognize a userscript
Press the new script button and paste this:
// ==UserScript==//
// @name a
// ==/UserScript==
Expected: The script is recognized and saved
Observed: Invalid script is displayed; it’s not saved
As you can see there’s a // after ==UserScript== but VM incorrectly expects a whitespace there although other managers (TM, GM) don’t. There’s also no such requirement in the GM wiki.
P.S. On the other hand, this regexp used by VM has \/\/\s+== which is too lax: it will allow linebreaks which is definitely wrong so [\t\x20]+ should be used instead, AFAICT.
Environment
- Browser: Chrome
- Browser version: 74, 79
- Violentmonkey version: 2.11.2
- OS: Windows
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 16 (8 by maintainers)
My point was not the length of coding, certainly. The point was that I instantly recognize this practice of hardcoding text positions, which belongs to the ancient past when everyone’s approach to parsing was inflexible, simplistic, and totally arbitrary. Hardcoding the position of a comment as well as the amount of spaces inside (
//must be followed by exactly one space) is pretty much the essence of that lazy legacy approach. The security argument doesn’t make a lot of sense especially since no one thought about limiting the amount of spaces after a@key. Moreover, 99.999% of users wouldn’t understand if a script is malicious anyway even if they look at the code. You and me already agree that the proper way to is to parse and present this info in a readable form.Edit: we can just agree to disagree as I see these restrictions on spacing/positions as a very embarrassing artifact of the past that thankfully is vanishing (nowadays we can see such lazy approach mostly in the legacy corporate/government software).
Edit2: one can argue userscripts are an artifact of the past so it should be preserved as is like a dinosaur bone. Maybe. To me userscripts are still useful so naturally I want to incorporate the modern approaches, like flexible parsing and proper installation UI. Also, a perfect example of this combined approach (flexibility + UI) is the web/chrome extensions which are so much more powerful but still allow any amount of spaces in their manifest.json.
GM wiki is quite restrictive by the way, unlike Tampermonkey:
At first, it might seem reasonable but in real world people can add or remove a space as it’s not something bad from a human point of view. Moreover it’s not like GM still holds some kind of authority over userscripts. So I suggest to keep being more forgiving about these spaces and thus more human-friendly (similarly to TM which isn’t opinionated about these things either).