Local script development

[martixy]

The blog has this article: How to edit scripts with your favorite editor?

However I found it quite confusing - it took me a long time to figure out how to get VM to sync. And quite weird - why do we need to be told you can edit javascript with your favourite editor?

Would there be interest in rewriting and updating it? Or perhaps writing a completely new article, and leaving the old one in place.

I was considering doing that - but I don't want to start if the PR is just going to be rejected after I've done all the work.

To give an outline of how I'd update it:

• Remove the "Hey you can edit scripts in your favourite editor" part, or at least rephrase it - I fail to see how being told that has any value.
• Update the screenshots where applicable.
• Be painfully clear how sync works.
• Include the @require option for local development.

Would such contribution be welcome?

And what would be the preferred way - write a completely new article, or change/rewrite the old one?

[tophf]

Generally I'm supportive of the idea. Yes, the screenshots should be updated and a video/gif may be added. The article is indeed outdated and may be improved, even though technically it's still correct. The process is simpler now in Firefox i.e. you don't need to install a web server, but simply keep the original file:// tab open in addition to the installer tab. But I don't think removing the favorite editor part has any value. Maybe it can be rephrased. Its purpose is to explain you don't have to suffer using the editor inside the extension.

"Be painfully clear how sync works." Include the @require option for local development.

What do you mean specifically? Please elaborate.

[martixy]

1. I found it confusing at what stage in the process sync works. So I'd present it as a list of steps like: a) Drag file. b) Tick the checkbox "Track local file before this window is closed" c) Click install, but do not close the window While this window is still open, the file will now be tracked. (For me the part that confused me the most is having to click install, but not yet closing the window. Other people seem to be confused by the procedure as well.)
2. You may develop locally without having to keep the installation window open by @require-ing the local file (on chromium, with local file access allowed). This is the method I've used for years. I've even written my own yeoman-like project (very old!). Thank you for mentioning Firefox - I would never have figured that out. I've been using chrome for userscripts practically exclusively due to its support of file urls for extensions. I'll make sure to cover FF if we move forward.

---

As a side-note I looked at how that whole page works. Serendipitously it's written with vue, which is my preferred front end thing, so I could easily navigate the code. Because I was curious why my script wasn't updating when I ran it off my own server. After all whether it's file:// or http://, it's still a URL and those can point to anywhere on the web or file system, network or local. Turns out the app explicitly checks whether the URL is local with a regex before turning on a 0.5 sec polling routine. (Although curiously I was seeing intervals of 1 sec at one time. Ah well.) And I had tried running it off my public domain address.

This would be an issue with the extension itself, but I would probably rename the checkbox to "Track local file changes while this window is open." with like an ℹ that tells you exactly what local means. Cuz seeing the source of the script one might reasonably conclude any url would work. But it don't.

Or... perhaps redesign how the interactions on that page work - after all the check boxes are mutually exclusive. Instead of having check boxes, I was thinking of 2 buttons:

[Install and close window]
[Install and track local file changes]
ℹ Changes to the local file will be synced as long as this window remains open. A local file is one with a file url, or known local urls such as localhost, 192.168.x.x or similar.

After all you cannot edit the script on that page and there is no reason to remain on that page beyond those two mutually exclusive user actions.

Should I open this as an issue in the VM repo? (It would be a good idea to make such a change before writing an article that would reference the changed parts.)

---

Also the question remains - write new article or edit the old one?

[tophf]

The article may start with a very concise list of actions, probably separate for Chrome and Firefox:

1. enable file access for local files in Chrome or use a localhost server
2. drag'n'drop a file from the disk or open a localhost URL
3. click the checkbox
4. click install
5. don't close the tab; in Firefox also don't close the source file:// tab when opening directly from disk

Then maybe two gifs, for Chrome and Firefox. Then a few notes e.g. about setting up a localhost server.

As for the extension's UI, we should probably show this list when "Use another editor" link is clicked inside the editor so that the info is available without a network connection. There'll be of course a link to the full article.

I also like the idea with buttons. Maybe Install, Install and close, Track local edits. The last one will be shown only for compatible URLs. When pressed the button will appear "activated" so it can be pressed again. A notice should appear reminding not to close the tab and optionally another notice in Firefox when a file:// URL is used.

The button to install and keep the tab open should remain for compatibility.

AFAIK, currently we don't implement @require with passthrough loading of local URLs like Tampermonkey does. In Violentmonkey these get updated only by the auto-update scheduler.

@gera2ld, WDYT?

[martixy]

Yea, exactly, a list of explicit steps based on browser that would be easy to follow.

Some notes:

1. If the Track local edits button does not also install the script it acts as the check box already does, and there is no reason to change it. Check-boxes work fine for signalling state.
2. It should not be shown only when valid, as that can appear arbitrary. It should be disabled, with a clear explanation of why it is disabled and under what circumstance it is enabled.
3. Hm. I saw @require worked when I tested and figured it's the same, but it seems that all requires are cached. "Passthrough" in this case simply means that TM reloads all requires on script execution, while VM does not. IMO it'd be cool if there was another method for local dev.

[tophf]

No, Track local edits is a button, not a checkbox, so it would do what it says and start tracking local edits when pressed. I think the word "Install" is redundant. I don't think it should be always shown because it's not necessary for like 99% of users.