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.

jQuery UI breaks Visual Studio 2015 Intellisense

I am finding a frustrating issue with JavaScript intellisense where if I include jQuery UI in my _references.js file I lose all JavaScript intellisense. Does anyone know if there is a way to fix this problem beyond removing jQuery UI from the _references.js?
Update
I do know that more files in the _references.js file will cause it to slow down, that makes sense. However, I have projects at work which include far more files (on the order of 600) with no typesense issues, and my project has 20. So it's not a matter of "too many files."
I pulled my project from Git to a separate computer (therefore separate installation of VS15) and tried including the jQuery UI file and this still caused the loss of intellisense in my project.
It can't be an installation issue since other work projects include jQuery UI and there are no intellisense issues
I do realize that I can manually manage _references.js to accomplish the task, but I would like to fix it altogether since I hate needing to add information twice (create the JS file and then update _refernces.js).
With this new information, I'm thinking it must be some type of deeper issue in my project's setup that is causing the issue as opposed to an installation based issue or jQuery UI specific issue. Does anyone have any ideas on what settings in a .sln or .csproj file might cause JS Intellisense issues?

For those who experience this issue, I found that using jQuery 3.x was causing instellisense to break when jQuery UI was included in _references.js. My solution was using NuGet to change back to version 2.2.4 and everything started to work fine again.

I've got the same problem. I tried quite a few things but the only thing I could get to consistently work was to disable the auto sync feature and remove the jquery UI reference.
Intellisense also seems to slow down a good bit with more and more libraries, almost to the point it looks like it is not working.
I finally just got to the point where I only include my own scripts and jquery for helpful reminders on syntax.
Unfortunately this means I have to manually keep the _references.js file up to date but it's definitely better than it not working at all.
You can also limit your global references in the _references file and drag the script files that you want intellisense for to each view if you are like me where you have a script file for each view. That way you don't get intellisense for scripts that aren't even rendered to the view.

not sure if this will help you but have you added this to the top of your .js file?
/// <reference path="/scripts/jquery-3.1.1.js" />
that's the path that's made if you you've used NuGet to install jquery for your solution. If you've located your jquery file and intellisense file elsewhere use that path instead (I do believe they need to be in the same folder).

I found a better solution! Simple rename jquery-ui-1.12.1.js (or similar) to _jquery-ui-1.12.1.js. This will cause it to appear at the top BEFORE the conflicting jQuery 3 references in the _references.js file that cause intellisense to not work. Be sure to also update any script tag or BundleConfig.cs references you have to include the new underscore character prefix!

Solution:
In your _references.js file:
Move the JQuery-UI reference above the main JQuery reference
Disable auto-sync
such as:
/// <autosync enabled="false" />
/// <reference path="jquery-ui-1.12.1.js" />
/// <reference path="jquery-3.3.1.js" />
Drawbacks:
You will have to repeat step 1 every time you Update JavaScript References (right-click on _references.js to update references in Visual Studio).

Always install jQuery first any version you like and then install JQuery-ui. If you want
to upgrade or degrade version of JQuery, you have to uninstall and again install JQuery-ui every time you do changes. First Jquery-3.6.0.js then Jquery-ui-1.12.1.js and you have to reinstall jquery-ui every time you make changes in jquery.

what is a preferred way to include bootstrap jQuery etc libs into project?

I recently started using js libs and have a question regarding them.
It's possible to include their source, but then there is a problem with versions, as there are two options: add version to file name, but then all includes will have version appended to file name, which will cause trouble when you will update version. If version isn't specified in file name it's not clear what version is, but it's not that big problem, as you can go inside js source and see it's version.
Another option is to link to libraries hosting url, but it'll add additional overhead to download them and when external host will be unreachable, your site won't be able to load that library.
There seem to be maven plugins for some js libraries, but they are usually 3rd party and frequently they refer to outdated versions.
The ideal solution will be something maven-like but with official support.
Also as a comment advises it's possible to use some sort of bundling, but bundling happens after building, so it's still a question how to keep those js libs before bungling.
Please advise.

For many projects it is not necessary to stay at the bleeding edge of 3rd party libraries. Like for jQuery, a new version can maybe break some of the plugins you use. So you have to check and test everything first before deploying a new version.
Having the version in the filename is considered good practice though, because it prevents caching issues and allows you to cache files for a very long time (since the browser will always download a file when the filename has changed).
Regarding the issue you pointed out with the libraries hosting url, they are true so far. But you also need to consider, that when those are widely used (which they are) the library may already be cached in your browser and therefore the browser won't need to download it again. You can check out https://developers.google.com/speed/libraries/devguide for a library hosting by Google, which you can expect to be pretty reliable I guess.
All that being said, it depends on the project. If you need 100% reliability you need to host the library by yourself. If you're fine with Google's reliability, go for library hosting.
As your edit pointed out bundling: https://github.com/bower/bower check this out. It is a package manager for installing dependencies etc. on frontend projects. Should be exactly what you're looking for.

Managing jQuery Plugins

Often, when working with jQuery, the need arises to include multiple plugins. This can quickly become messy work, especially when some plugins require additional components (images and CSS files).
What are some of the "recommended" ways to:
a. Manage the required files/components (.js, .css and images) in a way that is easy to maintain, and;
b. Keep these plugin packages updated to the latest versions
I'm not necessarily looking for a tool to do this (although one that could perform this management would be useful, I suppose), but more of a way of thinking.

Update: These days there is Bower, Component and Browserify which take care of all of the following for us automatically.
I'm surprised no one has covered what I do yet. So here's how I manage scripts and resources.
I have each project I work on setup with SVN. Nearly all of the scripts I include have a SVN mirror (github has svn these days) this means that I can then use SVN externals and fetch whatever branch or version or whatever I want of that project directly into the projects scripts folder. As we are using SVN, it is easy to track, manage and update these scripts.
If a project is not on SVN, then I just add it to a common SVN project I have made, so for instance Project A and Project B, both use jquery-project-not-in-svn, so we stick jquery-project-not-in-svn into our common project's SVN repository, and then use SVN externals on Projects A and B to reference it - as explained before.
Now that covers managing, fetching and updating.
Here is how I cover script inclusions and requests.
As each project now has it's own scripts directory that contains all the scripts it needs (which is managed by SVN externals), we now have to worry about minifying them to reduce load on our server. Each project has a Makefile in it's root, which contains the command update. This command will perform the following:
Perform a SVN update (this will update all SVN externals appropriately)
Once that is done, it will pack and minify all the js files into scripts/all.js and scripts/all.min.js
I can't share the exact Makefile but I can share one which is public that handles packing/merging and minification of CSS and Javascript. Here is the link:
http://github.com/balupton/jquery-sparkle/blob/9921fcbf1cbeab7a4f2f875a91cb8548f3f65721/Makefile
By doing these things, we have achieved:
Management of external script resources over multiple projects
Updating of appropriate script resources automatically
Packing all used script resources of the project into one file
Minifying that file, such that only one JS request and one CSS request are performed.
So good luckmate, feel free to post a comment if you would like to learn more.

I would recommend not updating them unless you are experiencing a problem with the version you have or you would like to use a new feature available in the updated plugin. As the saying goes, if it ain't broke, don't fix it.

My own personal "recommended" way is to keep all my JavaScript files in one include folder, all CSS files in another, and all images in a third directory. I write shortcut functions for my projects that I can then use like <?php scriptlink( 'jquery.tooltip' ); ?> or <?php stylelink( 'jquery.thickbox' ); ?>. Each shortcut function takes a filename (only) as an argument and outputs the full HTML tag for that resource type, i.e. (in order) <script type="text/javascript" src="/includes/js/jquery.tooltip.js"></script> or <link rel="stylesheet" href="/includes/css/jquery.thickbox.css" />
Most jQuery plugins I've run across that require images allow either specifying a configuration variable in the script itself or in the code used to invoke the plugin. Stylesheets are quite easily included without mucking about with the script.
So far this method has kept me pretty sane, so I think it works rather well. I don't tear my hair out over where I stuck a particular plugin; I just include it with a function. (The system also supports subdirectories of the include directory, so e.g. <?php scriptlink( 'ui/accordion' ); ?> equals <script type="text/javascript" src="/includes/js/ui/accordion.js"></script>.)
YMMV of course, but the only issue I've had at all is with upgrades when plugin authors start distributing a jquery.plugin.pack.js version instead of jquery.plugin.min.js or vice versa, because I actually have to remember to change the filenames I look for.
(Since I've omitted the implementation of those simple functions, perhaps your version will check for different variants of the file name given. If the argument to scriptlink() is jquery.plugin, the function might check the file system to see if jquery.plugin.pack.js exists, and if not look for jquery.plugin.min.js, and if not look for jquery.plugin.js, etc.)

CDNs are great but not for debugging. Sometimes debugging really requires local access
to the scripts and CDNs are useless until in production mode. For this reason I still like
to keep both debug and minified versions around then compare results and benchmark response time until we shift to production.

All of my jQuery plugins are organised into subfolders which include the version number e.g.
/assets/js/plugin.1.4.1/plugin.1.4.1.min.js
/assets/js/plugin.1.4.1/images/image.gif
If I need to update to 1.4.2 I can drop it in a new folder without too many problem, I can even use a specific version of the plugin in different parts of the site if needed. When I site is large and your using a few different plugins it's helpful to quickly see version numbers without digging around source comments in a plugin.js file.
If a plugin requires CSS I will take the base styles out of the plugin CSS and bundle these in with my main stylesheet, requesting additional CSS files is expensive and 9 times out of 10 it will be customised anyway. Likewise with images, if I'm doing any image customisation I will bundle these into my main image sprite, otherwise I'll just link to the images into that plugin.1.4.1 directory.
Yes, you end up with a few more files in your repo but it means:
you can easily upgrade plugins just by updating your paths
you can debug plugin issues easier because you can see how out of date you are
you can roll back to an earlier version if everything breaks

You could utilize the Google CDN (Content Delivery Network) for more popular plug-ins. Google keeps it up-to-date, you can quickly choose/switch between versions, and you also get the benefits of caching from other websites that use CDN.
Example for jQuery:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js"></script>
And, if you want to use a higher version automatically, change the version to 1.4 (automatic 1.4.x updates) or even 1 (automatic 1.x.x updates). Unfortunately not all plug-ins are available, but many of the major ones are.

Why does dumping all JavaScript files into one giant file change their behavior?

I took a snapshot of the jquery.js file and jquery-ui files that I use and dumped them into a giant .js file with all of the other .js files that I use for my site.
When I do just this with no minfication/packing, the files stop working and I get "recursion too deep" errors on the file when I try to load it on my site instead of the usual .js files. All of the errors came from jquery and jquery-ui. Using a simple numbering scheme I made sure that the jquery.js/jquery-ui files were the first listed in the file and in the correct order (the same as includes as individual files.)
Two questions:
1) Doesn't the include tags for JavaScript have the same effect as dumping all of the files into one giant file? Is there extra isolation/insulation that JavaScript files get from being in their own script tags or in different files?
2) My goal is to make my site faster by having one huge .js file with all JavaScript I ever use in my site (which is heavy in JQuery) and minify that file. Why is this misguided? What is a better way to do it?
NOTE: Google's CDN version of the JQuery files don't work for me, all of the JQuery plugins/themes I use don't work with Google's versions (anyway who says that they can successfully use Google's CDN is lying.)
UPDATE: Thanks for the good advice in the answers, all of it helped me learn more about deploying JavaScript files on a production server. I am actually always using the latest SVN branch of the JQuery UI plugins and there were errors in the UI plugins that prevented them from being merged together with my files. I got the latest Theme Rolled plugins that are already minified in one file and that worked around the problem.

Probably your JavaScript files have some syntax errors. Browser can correct them when loading files one by one, but fail when "bad" files combined. You can try to compile your file using Rhino compiler (http://www.mozilla.org/rhino/)
java -cp build/js.jar org.mozilla.javascript.tools.jsc.Main giant.js
Also you can use JSLint validator (http://www.jslint.com/), thought likelly it will not be able to handle jQuery. But you still can combine all your files and validate them.

I'd recommend using a script manager such as this one to only register the files and plugins you need, and load them on the fly.
This keeps your requests to a minimum, and you don't have to load some huge 300k JS file one very page.

Another problem could be the load order changed. Most JavaScript files should be load order independent, but if you load jquery at the end after you have your:
$(document).ready(function() {});
you'll run into problems.