[Feature] Add integration to https://vscode.dev

[mevanlc]

Motivation
Someone (3rd party, I think) has developed an extension for Chrome ("Tampermonkey Editors") that allows you to edit your Tampermonkey scripts in vscode.dev.

https://chromewebstore.google.com/detail/tampermonkey-editors/lieodnapokbjkkdkhdljlllmgkmdokcm

This is really cool because of how feature-rich vscode is as a JavaScript editor. I think it'd be awesome if Violentmonkey could build this functionality into the VM core browser extension -- or maybe someone from the VM community would be interested in creating a second extension for this purpose.

Proposed Solution
I don't know how the Tampermonkey Editors extension works, but it does load vscode.dev with the query param ?connectTo=tampermonkey. I suppose it's possible that this extension detects the presence of that query param and injects some code into vscode.dev to create a vscode filesystem provider that exposes the datastore of userscripts.

Use Cases
vscode is really a joy to use for programming JavaScript, and it'd be cool if VM could stay competitive with TM on this feature.

[cyfung1031]

Someone (3rd party, I think) has developed an extension for Chrome ("Tampermonkey Editors")

Jan Biniok (derjanb) is the developer of both Tampermonkey and Tampermonkey Editors. He has full control of the whole stuffs.

I don't know how the Tampermonkey Editors extension works

The two extensions communicate with each other. I tried to find out how it works, but Tampermonkey is closed source...

[tophf]

Yeah, I thought about it myself, but I lack motivation because I use a local IDE + tracking.

Tampermonkey is closed source

FWIW, it's not obfuscated, so you can debug it in devtools, but it shouldn't be really necessary because the idea itself is clear and straightforward: open the site, find its internal API or editor instance in the MAIN world and use it directly.

[cyfung1031]

I am interesting in it coz I want to use better syntax highlighting and refractor features provided by Monaco Editor.
I did not know "Tampermonkey Editors" before. It gives me a direction to make the universal plugin for userscripts and userstyles (Violentmonkey and Stylus).

I am now studying the required APIs to make the communications.

[cyfung1031]

@tophf

WebCoder for Extensions

I have drafted the extension. I think it might not be good to put it inside VM. Just like TM to keep it as a separate extension.

(To be published in Chrome Store later; take it as a reference for your coding in VM first)

As it use onConnectExternal API to communicate, there is no performance issue if the users do not install the 3rd party extension.

There are some APIs to be provided by VM via background page's chrome.runtime.onConnectExternal
(See this demo extension to understand the responses to be provided by VM)

options

• to provide a list of options that can be communicated (just to align with TM)

list

• to get all the files to be viewed/edited in the editor. Currently all the files are editable. File Locks to be available. You might imagine there is a "readOnly" property (true or false) in each file entry.

get

• to get the file content

patch

• to set the file content

TM use the following urls for the communication. You can use different syntax as these are just for the file addressing.

[
    {
        "name": "script.user.js",
        "unders": [
            "Violentmonkey Scripts",
            "New Userscript 1"
        ],
        "path": "ce6a2ec5-fb09-4de9-853a-e0a70c5da20e/source"
    },
    {
        "name": "script.user.js",
        "unders": [
            "Violentmonkey Scripts",
            "New Userscript 2"
        ],
        "path": "dc50ca86-42fc-4df8-949c-90f7e68acee0/source"
    },
    {
        "name": "script.user.js",
        "unders": [
            "https://gitstore.com/iFelix18",
            "Greasy Fork++"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/source"
    },
    {
        "name": "storage.json",
        "unders": [
            "https://gitstore.com/iFelix18",
            "Greasy Fork++"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/storage"
    },
    {
        "name": "https://fastly.jsdelivr.net/gh/sizzlemctwizzle/GM_config@06f2015c04db3aaab9717298394ca4f025802873/gm_config.min.js",
        "unders": [
            "https://gitstore.com/iFelix18",
            "Greasy Fork++",
            "external"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/external/https%3A%2F%2Ffastly.jsdelivr.net%2Fgh%2Fsizzlemctwizzle%2FGM_config%4006f2015c04db3aaab9717298394ca4f025802873%2Fgm_config.min.js"
    },
    {
        "name": "https://fastly.jsdelivr.net/npm/@violentmonkey/shortcut@1.4.1/dist/index.min.js",
        "unders": [
            "https://gitstore.com/iFelix18",
            "Greasy Fork++",
            "external"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/external/https%3A%2F%2Ffastly.jsdelivr.net%2Fnpm%2F%40violentmonkey%2Fshortcut%401.4.1%2Fdist%2Findex.min.js"
    },
    {
        "name": "https://fastly.jsdelivr.net/gh/roger810/userscript-supports@3fa07109efca28a21094488431363862ccd52d7c/library/WinComm.min.js",
        "unders": [
            "https://gitstore.com/iFelix18",
            "Greasy Fork++",
            "external"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/external/https%3A%2F%2Ffastly.jsdelivr.net%2Fgh%2Froger810%2Fuserscript-supports%403fa07109efca28a21094488431363862ccd52d7c%2Flibrary%2FWinComm.min.js"
    }
]

The actual directory shown in the editor is the "unders". So the users will see the file in the editor with your custom file directory and file name.

For TM, script.user.js and storage.json are used. However, I think VM can give the actual js file names instead of the meaningless file names.

Usage is just the same at this moment.
The offline PWA version will be made later.
https://vscode.dev/?connectTo=userjs

Access Token

I made the concept of access token in this extension. You can totally ignore it if you don't need it.
It can let the userscript managers to deny the connection.
The token is returned in options request.

---

You can check the mock response (incoming & outgoing) in mock extension's background page.

[tophf]

I don't see any benefit in having a separate extension.

[cyfung1031]

I don't see any benefit in having a separate extension.

It can edit files in Stylus and VM in a same coding editor.
With vscode.dev, it can make use or the coding hints or method/parameters descriptions in its online resource.

VM and Stylus can just focus on their own functionality. As you know the editor in VM is quite basic with some syntax highlighting only using CodeMirror 5. And there are formatting issues in Stylus for stylus-language coding.

You can just add this communication features to the external extensions so that people can have a better coding environment easily. It is no harm to VM itself. All the file control is still under VM scope.

Besides, the local filing tracking option loses the control of the filing. VM itself does not know the editing. For the auto-update scripts, there might be problems. (and it requires the access local files permission in the browser. by using 3rd party extension option, such permission is not required)

Also, it gives the ability to edit the GM storage settings directly. Of course it can be read-only which is controlled by VM side.

All I want is that we can have a tool to edit the userscript and userstyle with modern coding IDE environment. We do not need a local application to do it.

[tophf]

I've quickly looked at your extension and I'm surprised there's so much code and overrides in the MAIN world. Why?

Besides, the local filing tracking option loses the control of the filing.

I don't understand. Local editing is for the userscript author and the author is in control of everything.

requires the access local files permission in the browser

Only in ancient Chrome before 86. See 2.16 release notes.

We do not need a local application to do it.

I need it because anything web-based is inferior and unreliable compared to a local IDE.

[tophf]

Assuming all that complexity is really needed, I guess a separate extension would make sense indeed but I don't think we should allow it to see the list of the installed scripts. Instead I'd prefer that Violentmonkey sends the message to the extension, which will then load the script in vscode.

@gera2ld, please read the thread. It's close to your idea of an external editor app.

[cyfung1031]

I've quickly looked at your extension and I'm surprised there's so much code and overrides in the MAIN world. Why?

1. It just like Userscripts. It uses some JS scripting to mock the FileHandle so that when it open the file, it will refer to the coding in the MAIN world and then send to Content Script and then send to Background (Service Worker) to communicate with external extensions.

2. There are some implementations for keeping the background alive while opening the editor page. This is MV3 bug for service worker. This will keep the connection during the editing.

Besides, the local filing tracking option loses the control of the filing.

Just like our previous discussion in "Auto-Update". If "Auto-Update" without "allow edit", the author can still be able to edit the file externally and then it will become a conflict in VM control.

I need it because anything web-based is inferior and unreliable compared to a local IDE.

This is just an option. The users think themselves. If they like to edit in browser, this is their choice.

[cyfung1031]

Assuming all that complexity is really needed, I guess a separate extension would make sense indeed but I don't think we should allow it to see the list of the installed scripts. Instead I'd prefer that Violentmonkey sends the message to the extension, which will then load the script in vscode.

This is possible.

The communication flow is like this.

Open the web page -> detected by WebCoder -> search the available extensions installed -> create connections to them to ask for option
(i.e.

If the ext. extension can feedback correctly against option, it means that the extension is willing to communicate with WebCoder.

Then WebCoder will send the list action to VM. VM can have its own control to send back what to display.
It just needs the folder structure. Not the exact content. You can hide any file in the file structure
( VM can have its own setting or decisions to show the GM settings or not. )

Then come to the read/write process.

When the user click on the file, WebCoder will send get action to VM. VM can response it or not. It can send back with some error message. If it is ok, VM sends back the file content.

When the user saves the file, WebCoder will send patch action to VM. VM can response it or not. It can send back with some error message. If it is ok, VM changes the file and send back the response for the modification timestamp.

[tophf]

Just like our previous discussion in "Auto-Update". If "Auto-Update" without "allow edit", the author can still be able to edit the file externally and then it will become a conflict in VM control.

There will be a conflict regardless of how the file is edited, because locally editing a file auto-updatable from an external source is inherently nonsensical.

When the user click on the file, WebCoder will send get action to VM

Well, I don't like the idea of having an external extension that we don't have control over to have full access to the contents of any script and see the list of all scripts. I want the workflow to be fully controlled by the user clicking the "edit" button/icon in Violentmonkey.

[cyfung1031]

There will be a conflict regardless of how the file is edited, because locally editing a file auto-updatable from an external source is inherently nonsensical.

When the edit request is sent to VM, VM can deny the file modification and send back the error after VM's own checking on whether the file can be modified or not.

In this case, the user shall click the "Allow Edit" in VM first. then switch back to the editor for editing.

Well, I don't like the idea of having an external extension that we don't have control over to have full access to the contents of any script and see the list of all scripts. I want the workflow to be fully controlled by the user clicking the "edit" button/icon in Violentmonkey.

I mean the read (get) request will be sent to VM when the user click on the file name in the editor.

This is fully controlled by VM. (including the file tree. this is just a virtual file tree based on what VM told in "list" response)
VM is responsible for the file updating and file reading.
This 3rd party extension has no ability to directly view or edit the file. It just store the unique address path for communicate.
It communicates with VM to get file content and write file content.

---

for example, a file entry is retrieved from VM

    {
        "name": "script1.user.js",
        "unders": [
            "MyScript",
            "Hello World"
        ],
        "path": "0d334a55-7003-4d2e-8625-8ea95c6df28c/source"
    }

In WebCoder, it will just know there is a file called "script1.user.js" located in "MyScript/Hello World" folder. Its true address is "0d334a55-7003-4d2e-8625-8ea95c6df28c/source".
It will ask VM the content about what is "0d334a55-7003-4d2e-8625-8ea95c6df28c/source" and show in the editor.
For saving, it will tell VM that the user wants to update "0d334a55-7003-4d2e-8625-8ea95c6df28c/source" to the new content. Then VM do the saving. VM can deny too.

Summary

There is no file editing and reading features provided in WebCoder itself. It just communicate to VM to let VM action.

The File Tree is virtual based on VM's response.

[tophf]

I can understand the appeal of the alternative approach that you suggest, but I meant I'd like this workflow:

1. The user opens the popup/dashboard in Violentmonkey and clicks "edit"
2. The request is sent to the editor extension and it shows the file
3. As long as the messaging port is open the edits are tracked by Violentmonkey without showing the installation page.

Anyway, let's wait for @gera2ld, maybe he'll have a different idea.

[derjanb]

I have drafted the extension.
To be published in Chrome Store later

@cyfung1031, are you serious about taking the code from my browser extension, publishing it under an Apache-2.0 license on Github, and wanting to upload it to the Chrome Store?

When @gera2ld "ported" Violentmonkey to Chrome, he obviously used Tampermonkey as a blueprint and even adopted bugs from Tampermonkey's code base, which were later fixed.
That is OK insofar as, in my view, he never copied a line of code, and I occasionally get something back in return. @tophf's iframe implementation for clean globals was a very good idea, which I then implemented as well.

But "WebCoder for Extensions" is something completely different. You took the minified code, had it formatted by a prettifier, renamed a few classes, and added (in my opinion) useless code.

Since I published Tampermonkey Editors over a year ago, DMCA takedowns of the repository and a Chrome extension shouldn't be a problem.

Nevertheless, a suggestion for a compromise: You are welcome to continue using the code if you change the license to MIT and adopt the license file from my repo, where I will publish the code of Tampermonkey Editors. You may even want to fork this repo later, since it'll contain a clean TypeScript code base.

Actually, I wanted to clean up the code a bit first, but I can do that later. This, for example and just in case you ever wondered, is code that was only needed in the Tampermonkey extension when the page uses document.write, which is not the case on vscode.dev.

[gera2ld]

My idea was: To create a web version of VSCode, with a built-in VSCode extension to communicate with Violentmonkey, working as a replacement of the built-in editor and part of the dashboard. There should be just a few filesystem-like APIs so it is not necessary to create a separate browser extension for it. The website should be whitelisted and under our control and better to be loaded within Violentmonkey (as an iframe?) to avoid being injected by other extensions. With the power of VSCode, we may even allow users to write TypeScript directly.

However, I lost my interest after proving its feasibility because I use Vim and it's much better than an editor in a browser.

Anyway here is the flow in my mind:

• In a whitelisted website (either hard-coded or user specified), we expose APIs.
• User requests authorization from the website.
• Grant permissions (selected scripts, all scripts, management, etc.) from Violentmonkey.
• The website communicates with Violentmonkey until the tab is closed (or in a period of time).

[cyfung1031]

Nevertheless, a suggestion for a compromise: You are welcome to continue using the code if you change the license to MIT and adopt the license file from my repo, where I will publish the code of Tampermonkey Editors. You may even want to fork this repo later, since it'll contain a clean TypeScript code base.

@derjanb Thank you so much for letting us to continue this stuff :)
Although I am not going to fork your code and I am going to rewrite the FileHandling Classes by myself, I will use your MIT license to make you happy. ( I am not interested in TypeScript by the way )

• License File has been changed to MIT License :)

I just keep the API syntax (option, list, get, patch) cause I think it will be great that the editor extension can also communicate to Tampermonkey as well. So people can just use one extension to edit all.

Thanks for having your time here. Besides, could you please have a look on the Orion's discussion regarding Tampermonkey's compatibility? That's a great browser based on Webkit engine to try to work as Chrome / Firefox. We solved the issue with Violentmonkey but not Tampermonkey. (see https://orionfeedback.org/d/547/)

There should be just a few filesystem-like APIs so it is not necessary to create a separate browser extension for it.

@tophf @gera2ld

• It acts like a plugin for the original vscode. It gives the ability to users to edit/view the virtual file systems in other extensions. This is the main purpose of WebCoder.

• WebCoder would add the feasibility to view/edit the virtual files stored in the extensions like Tampermonkey, Violentmonkey, Stylus, etc. (those files are not accessible in actual local file system)

• We can easily edit and update the files (which is invisible in the actual file system) for developing the Userscripts/Userstyles. It can work as an IDE since PWA standalone (+ offline mode) is allowed for extensions.

In short, VM would be just a folder root in the editor. People can open other local files or do other things as well. People can edit local files and VM files in a same window.

Communication Modes

• All extensions just need to communicate with the extension in background, to provide the virtual directory to this extension. (No need to duplicate the filesystem API modifications again and again for each userscript manager)

• I believe you both are using the local IDE with the file tracking option, but editing in browser in one tab and testing in another tab is also common.

From WebCoder to VM

• This is what the draft extension is doing now which is the same way as Tampermonkey Editor does. WebCoder ask the virtual directory and let users edit. VM has to verify the operation and do file operation by itself to send back the responses to WebCoder. (All scripts are exposed for easy editing)

• For security concern, you can do the alert / prompt to ask users whether it is trusted or not for each editor webpage. Users have to click ok otherwise VM would not response to it.

• You can also add an option in VM to disable this option by default.

From VM to WebCoder

• This is also possible, just like what you are thinking. You can call WebCoder from VM with a token key so that only that would be allowed for communication. So it will the edit button in VM setting page is clicked, the VSCode editor will be opened in either a tab or a iframe. (All other scripts can be hidden for what you are concerning)

• As said, if this is controlled by VM's iframe, the VSCode would lose the ability to reopen the history files.

[Feature for not built-in in VM] Separate Window (App) <Not yet implemented, but concept proved>

• This extension will work in PWA offline mode as well, in a separate window like native IDE. It will be just like a native App.

[Feature for not built-in in VM] History Record <Not yet implemented, but concept proved>

• As it can have the history tacking, the whole VSCode.dev will be injected not just iframe. For example, there is a history item for VM virtual folder, and the user should able to click it to open and view/edit the files. Of course the file content be controlled by VM itself.

Security Concern

• when there is a new access from a page (WebCoder -> VM), VM can do a prompt to ask about the permission. The file will be only viewed/edited if the pageId is approved.

With the power of VSCode, we may even allow users to write TypeScript directly.

I am not sure about it. I just want syntax and hints for JS scripts. This lets the public contribution.