Licensing...

[rslifka]

Licensing...

[rslifka]

Hi @Martii,

Apologies, that was not my intent! I only now just realized you could click the @license directive here for more information and examples. I do see now that a single directive per dependency is expected.

Done as of 34c4cb6 ! 😄

Does that look about right? Happy to make any other changes required here.

I'll also figure out why I'm not getting notifications from GitHub. I just happened to see this by chance 😞 (edit: it looks as though I need to Watch my own repos to get notifications about them)

[Martii]

Does that look about right?

Wishful but I don't think that's how that part would be accepted. The header (in Userscripts it's usually known as the metadata block) is per module so the dependencies would need their own... they usually do have their own headers but your minifier in brunch stripped them. This is why I gave you extra time otherwise it would have been gone the moment it was detected. Build systems are a pain sometimes.

Happy to make any other changes required here.

Since you know your build system better than I do... you may want to look into the last link I did above and see if you get your compressor to not do comments. I think I saw a specific package for brunch and uglify-js somewhere about here while I was investigating... but ran out of time, not real familiar with that particular build system, and still recovering from a SSD crash in the last couple of days (won't be trusting those to data anymore heh... all my VM's are toasted and regular data almost got fully toasted... but backed the remainder up and replaced several drives... anyhow). We do the keep comments on OUJS with minification.

An option available to you is to utilize OUJS to do this for your users and the upstream mirror of GM_config (this won't help with other projects unless they are on OUJS though...look at the orange clipboard icon for copying the minfied url minification)

I'll also figure out why I'm not getting notifications from GitHub

Eep. Good thing I do it in both sites when possible. ;)

(... it looks as though I need to Watch my own repos to get notifications about them)

Check your https://github.com/settings/emails and https://github.com/settings/notifications :)

... unlisted ...

Yes it is currently unlisted until resolved.

[Martii]

In case you need some uglify-js option reference it should be here:

• https://github.com/mishoo/UglifyJS2/blob/master/README.md#output-options
• Presuming the package supports this (and it might if it's truly uglify-js)... this is the current option block we use here to keep comments. Not sure what brunch uses by default... so that option may still need to be disabled.

[rslifka]

Wow, thanks for the detailed response @Martii, much appreciated! Digging in to things now...

[rslifka]

Thanks for the uglify pointer, that did the trick! I now see comments in the JS being output from the build, as of 1e10908

[rslifka]

Thanks @Martii, all good and published as the latest release on GitHub!

https://github.com/rslifka/fate_of_all_fools/releases/download/current/fateOfAllFools.js

Sorry I didn't figure this one out on my own - really appreciate your help here and OUJS! Can you confirm things are looking good?

[Martii]

really appreciate your help here and OUJS!

You're welcome... and thank you for responding. Some authors don't always respect the TOS.

Can you confirm things are looking good?

1. Seems to be good to go on keeping the comments... interesting that the plugin is already there and not needed to be mentioned in your package.json. This is why you know your build system better than I do. ;)
2. You should revert 34c4cb6 so that those other projects licenses don't confuse everyone especially on OUJS.

Thanks.

[rslifka]

Done, thanks @Martii! Brunch is pretty cool - does a lot of magic behind the scenes 😄

[Martii]

Ref:

• d761f2e

Brunch is pretty cool - does a lot of magic behind the scenes

Seems to be missing a little of that. ;) So looking at the current source generated from the @require in the .user.js how exactly is brunch expecting the last line to execute in a .user.js engine?

var GM_config = new GM_configStruct;
require("main.js"); // This is the last line

require isn't recognized I believe in content/page scripts... although doesn't seem to error out which is unexpected.

In general this is probably the most complicated build system I've seen to date and not exactly easy to follow to assist in debugging.

Took me a bit to find your actual start point too... See how we indicate for humans and npm in our package.json what that point is. Presuming this is accurate to use for your project you may want to do something similar in your package.json for an improved .user.js experience (this includes up and down votes) if possible. Again your build structure might be different than node and npm so don't know if there is a way to do that effectively.

Since your module actually seems to start at main.js that is where your @license'ing starts with the .user.js headers and your entry point Code.

Final note for the actual issue here on GH... Don't forget to @version bump, rebuild, and have it imported to OUJS e.g. perhaps your deployment appearing to have been skipped is the issue. I won't be able to relist your script until that is done over there. 😸

[rslifka]

Yeah @Martii, Brunch is definitely one of those love-it-or-hate-it things. Half of using it is figuring out what black magic / conventions it's doing behind the scenes that I'm sure I'll forget about in time :)

Nice catch on Travis - they recently updated images which threw things in to a tizzy. Updated build configuration to compensate and now it's releasing back to GitHub!

I just added the latest code back to OUJS so it should be good to go.

Thanks again so much for your help Martii!

[Martii]

I just added the latest code back to OUJS so it should be good to go.

Relisted.

Thanks again so much for your help Martii!

Welcome... but what about my question? :P

Did I miss a boat on an ES6+ feature using require in content/page scripts e.g. how (and where) does it look for main.js when it's not referenced anywhere as a dependency in the .user.js. Is it in the sites scope that it's calling or is this a bug in the build? (Btw this is a question as a regular user and not admin related... "timbah his arms open").

[Martii]

n/m... found the "registration" for main.js. Very unusual build system. More to ponder on at a later date.

Seems like it would be less likely to be speedy compared to a direct JavaScript implementation.

Brunch is definitely one of those love-it-or-hate-it things.

I would have to agree. Back to admin duties with this part... be careful you don't abstract it too much more. It's teetering on that fine line between obfuscation and minification. Took me a while to figure it out and that is a good thing because, starting at my ranking, we evaluate reports of scripts that may be obfuscated... having us understand what you, as an Author, are doing (not necessarily the "why") gives you an edge to avoid the default TOS action being applied.

Anyhow... time to go unburn some brain cells. ;) LOL

[rslifka]

Oops sorry I missed your question... yep it does define require, wrap everything in modules for you, etc. Took me a while to wrap my head around all this, and I'm still not quite sure I have 😄

If there's a template of Uglify settings / set of UserScript developer best-practices, I would happily implement those in to the project. OUJS is giving a great service the community and I'll take whatever steps I need to take to be in compliance.

Thanks again @Martii!

[Martii]

set of UserScript developer best-practices

The thing about uglify-js is that's it's configurable, usually to ones own tastes. The teetering with the TOS is currently on mangling because what does identifier t for example. I'm still trying to figure out why on a personal improvement level one would make these portions of your code modules in brunch but it's a background consideration for me at this time.

Pro for mangling:

• Smaller output for local storage... not necessarily for transmission since HTML has gzip'ing, or equivalent, on the fly for most MIME (Content-Types).

Con for mangling:

• Difficult to read... back to the BASIC interpreter days of 64KiB and one letter variables. ;) 10 P=3.1415. Sizzle requested to not mangle for OUJS itself... so we don't.
• Difficult to edit (outside of your repo here)
• As I mentioned earlier contributing can be a chore back referencing. Even with brunch it seems like it's less likely to be diagnosed by another party when an issue arises. Not everyone is GH savvy. Is clever how it all publishes to GH releases though.

This is why I brought up minification on OUJS so people could let the server do this real time... does take a bit longer as a pre-task (dynamic) compared to a static but worth the wait in my book and it's opt in. This way source code can always be in the clear and human readable. To each their own I guess. The only Admin+ consideration is readability to check for possible flagging. We do this for everyone even ourselves going up the chain... few of the higher ranks had their scripts removed too so it's not just a you thing. I, myself, try to keep open to new ideas but also allow basic protections.

Anyhow... I think you are okay as is now... I started out in C and BASIC... so I know how to read condensed identifiers. Takes a little more time to dedicate to reverse engineer though. :)

[rslifka]

Oh wow, I think there's a few things to learn here for me.

• I didn't realize that OUJS did minification in real time, interesting! I'm happy to remove minification (and therefore, Uglify entirely). I don't actually have a strong POV or really even a POV here. Just minified and compressed assuming that would be a best-practice. If I'm understanding you correctly you're saying "these are running in a privileged context on a user's machine - the value of minification is less than the value of transparency"... and that totally makes sense to me.

• The publishing thing all stems from needing @version updated at build time so updates are automatically picked up by clients and involved a lot of trial-and-error to get right. I would prefer having the running, current version script live on GitHub and synced by OUJS but:

1. Travis does the build to get a clean-room environment.
2. If the build is triggered by a commit to master, I can't have travis compile and place back on master or it builds infinitely (I may have made this mistake 😄 ).

If OUJS GitHub script importer / sync was able to pick a script up off of a branch other than master, that would totally work for me. Just makes it a little less transparent when you're browsing the UserScript's repo but you wouldn't really have to because the whole script contents would live at OUJS (and I could drop all the custom stuff I did about using GitHub Releases)

[Martii]

... POV ...

Hmmm think I'll take that acronym as "point of view"... search suggestion says something about adult films. 😸

the value of minification is less than the value of transparency

Too much minification is a better phrase... that's why it's teetering near the realm of obfuscation. You aren't the only person that mangles identifiers with static copies published. So not a huge deal to us.

Recall this line from me above of:

Presuming the package supports this (and it might if it's truly uglify-js)... this is the current option block we use here to keep comments.

... if you look up a little our whole config is at L755-L765 and doesn't mangle. Some may be a trial like the quotes but may solidify at some point like the rest. I gave you a refererence to uglify-js as well somewhere above. ;)

I didn't realize that OUJS did minification in real time

Where's that fish? ;) *slap, slap*. That's why the uglify-js config block exists in our project and I mentioned the orange button for GM_config.

these are running in a privileged context on a user's machine

Not entirely sure what you mean here... but we can optionally do the minification for a user. e.g. it is opt in via the Install button drop down. This is the number one reason why we keep comments... on your script with just headers the process would use GM defaults if we stripped the comments... so we tell the package instance not to.

If OUJS GitHub script importer / sync was able to pick a script up off of a branch other than master

Won't happen... and specifically it's the default branch. Read our repo issues regarding that from a search.

Travis does the build to get a clean-room environment.

Yah... use that over on a few other projects. For myself with OUJS it's too much of a hassle. I can retest quicker than they can run the queue... plus a site is more difficult to add tests to simulating authenticated users, adding extra db's, etc. ;) Travis can distill some bugs for sure and I do see it's value.

I can't have travis compile and place back on master or it builds infinitely

Other projects I've seen with CI don't do that... might be some config available to prevent your recursion. IDK.

The publishing thing all stems from needing @version updated...

A-ha... the truth is revealed for brunch. ;) Well perhaps this option... have you tried mastering a git hook? There are a few events there that might work for you. Although publishing to the releases might be manual. IDK never tried that and to see if that event exists. This also requires some "black magic" knowing your CLI in your platform.

Anywho... you have options... I'm not saying that you can't minfiy yourself but we have the ability as well. uglify-js does have bugs and sometimes we'll serve un-minified if we trap that.... but usually I keep on top of that since it's one of my additions to the site... and of course the source author (you) would need to check that minfication didn't bust something logically. e.g. does the script still work minified.

[Martii]

... live on GitHub ...

vs.

... live at OUJS ...

Btw have you looked at my primary script on OUJS? It is dual homed on GH and OUJS. GH is my SCM and OUJS is my presentation in a collective environment.