Develop Reference

How to implement plugins into Electron app?

I'm looking for a way to implement "Plugins" for my Electron tool.
Below is a pseudo example of how I'm thinking it would work
Supply .js/.zip/plugin file
File would contain name of plugin, and it's category (Global, Team centric, Misc)
File would contain HTML for the GUI, which get's placed in a div designated for tool space. This name would be added as an option to the necessary Select, as well as logic added to pull in the HTML to the same div
In the tool, select the plugin file:
page will load the JavaScript script, and add option to select along with logic to switch to the plugin
The hope is to automate my current process.
Currently I'm manually updating the index page to reference the new JavaScript script, and to add the option on the select
The JavaScript Script has logic in it looking at the Select, and looking to see if the option was selected
which then pulls in it's own HTML via a function within
Is there anything I can reference/utilize to make this work?

After 4+ months of working on this, I've managed to get this to work. I will try to outline my approach.
Each "plugin" or "tool" will need it's own .js file
the js file should contain an exports.html function that will return the html for the tool
the js file should contain an exports.Events function that adds all relevant event listeners
create a json file cataloging each tool, along with information needed i.e. a description, image path, .js file path, etc.
require the .js file when selected, load the html and the events
parse the json to figure out which tool to load along with needed info
all i need to do is update the json file and upload the .js file to add a new plugin.

I developed an electron app using vue as the front-end.
My idea was to develop plugins as vue plugins and publish via npm.
I used live-plugin-manager to install and uninstall plugins.
The dependencies were automatically removed by making use of a counter
The only problem I faced was how to load these installed plugins into my main app.
The workaround I found was posted as answer to my own question at How to use electron to load the vue plugins installed dynamically into a plugins folder
Hope it helps

I know I'm a little late to the party but I encountered the same problem. To solve it I have built a plugin framework for Electron called Pluggable Electron and it is available on npm.
The framework handles the lifecycle of plugins, provides as npm packages, like installation, activation, removal, etc. The plugins can then be called on at any time to exend the core app functionality.
The framework is still under development but you can find a 1st version here: pluggable-electron.
I expect it is too late for Marker but still answering here for anyone else that might have this question.

Angular 2+ server-side rendering with jQuery

I encountered something debilitating.
I'm pretty far in a project right now, and it definitely needs to be rendered server-side at some point.
The webapp lets users upload pictures such as profile picture and also "regular" pictures.
I'm using Croppie from Foliotek (https://github.com/Foliotek/Croppie) to do the cropping, which works well and is exactly what I need.
But Croppie relies on jQuery. Yesterday I found out that could be an issue if I want to make the app server-side rendered.
All the jQuery is used in ngAfterViewInit lifecycle hooks, so I'm hoping this makes it server-side rendering proof?
I know there is ng2-img-cropper available, but I'm not so keen to implement that one. BUT, if I can use ng2-img-cropper together with server-side rendering then I'll have to.
Or is there something far better I'm overlooking?

You can use jQuery on server, with Node, AFAIK. Just browse npm and search for suitable module. And do not forget, that Node have no DOM implementation, so you need module for virtual DOM also.
For example, you can use this jQuery wrapper with this DOM implementation. Example:
npm install jsdom
npm install jQuery
var jsdom = require('jsdom').jsdom
var myWindow = jsdom().createWindow()
var $ = require('jQuery')
var jq = require('jQuery').create()
var jQuery = require('jQuery').create(myWindow)
$("<h1>test passes</h1>").appendTo("body")
console.log($("body").html());

I found out there is an Angular Universal (server-side rendering) starter project available:
https://github.com/angular/universal-starter
I cloned it and implemented Croppie as I did in my development version and everything works just fine!
So... I wonder why I've read multiple times that things will totally break if using jQuery in your Angular 2+ SSR project. Also Max Schwarzmuller told so in his lectures on Udemy. Anyway. I'm happy to have found everything still works.

as i know, when ever jquery use "Window", ssr gets confused, because in server we don't have window(window is in browser).
but normally, jquery works.

How to update fragmented JQuery

With new version of Chrome, our shopping cart application stopped working, and we suspect that there's problem with the old JQuery library we are using. However, we are depending on multiple JQuery files as follows:
jquery-ui.js
jquery-corner.js
jquery-corner.js
jquery.js
jquery-printElement.js
jquery-spin.js
jquery-tmpl.js
jquery-waypoint.js
And we are not able to locate the cause of bug. We are using yuicompressor to compress our javascript libraries and application logic into a single file. Is our only choice to search and update all those files independently and hope to avoid conflicts, or does can I find these components in one package somewhere?

how do I make sublime recognize a javascript library

I have Javascript libraries downloaded in different folders, how do I set the path for them to be picked up by sublime. (and hopefully also show autocomplete for them)
I believe the right way to get the library into a js file is this:
var highcharts = require('highcharts');
Neither does it pick up the library nor does it do any autocomplete.
I've had problems with Emmet (same as the one mentioned here https://github.com/sergeche/emmet-sublime/issues/129) so I have the following plugins installed:
Javascript Next
Javascript Completions
SublimeCodeintel
SublimeLinter-jshint
For the autocompletions I've already asked a question (https://stackoverflow.com/questions/29079474/get-autocomplete-for-new-javascript-libraties-in-sublime) but the problem I want to get solved here is getting the library recognized and thereby suggest autocomplete.
Thanks.

Try All Autocomplete plugin, it finds matches in all open files of the current window.

Should I put the version number of my JavaScript library in the file name?

I am about to release a javascript library.
I would like to save the file as [library-name].1.0.0
Then as the library will evolve you will be able to download new versions, e.g.
[library-name].1.0.1.js
[library-name].1.0.2.js
[library-name].1.0.3.js
[library-name].1.1.0.js
[library-name].1.2.0.js
[library-name].2.0.0.js
My question is: is there any reason not to save the version in the name of the file?
I am using other 3rd party libraries and the ones for which I don't store the version I always have to figure out if I have to upgrade or not.
For instance, I use codemirror.js, and I always wonder if I am using the latest version.

If you are giving it for download, then its a good idea to have version number as part of file name. Also its a good idea to add version number along with the license info at the beginning of the file like jQuery does
Checkout - http://code.jquery.com/jquery-1.9.1.min.js
Only case where you shouldn't add version number is when you are referencing a script file throughout your website - because you don't want to change all references whenever you update the script.

I've never released any libraries myself, but putting the version number in the file name sounds like a fine idea to me.
On upgrading, I think not putting the version number in the file name is used for libraries where the author doesn't expect to introduce breaking changes in future versions, only bug fixes and additions that don't affect code already written against the library. This means that people who use the library but don't host it themselves (i.e. who point to the library on a public CDN) automatically point to the latest version, and thus get bug fixes without having to do anything.
But, as you say, for people who download the library and host it themselves, it does mean they have to open the library file to check the version number.
If you want to match what some other library publishers do, you might want to have a look at Semantic Versioning - it codifies the x.x.x version numbering system.
And if you're going to release your library through Github (which I believe is what the cool kids do these days), you might want to use Jonathan "Wolf" Rentzsch's system for doing semantic versioning there.

If you are using unit tests you can make sure that the V1 unit tests all work fine against V2 before releasing the library.
Smashing article on js unit testing

If I understood your question correctly, one reason not to include the version name is that if you're hosting the script users using that CDN-hosted file don't have to change any code when you upgrade.