Develop Reference

Is there a thing such as "packaged web app"?

Let's say I have a HTML/JS application, which is on a website and runs without any server-side component (except the web server, of course). So it's basically just a bunch of .html, .css and .js files (and some others, like images or SQLite databases)
Someday, an user comes to me to ask me if I can make an offline version, so they can access the app when they are offline.
My first reaction would be to provide them all the files of the app in a .zip file or something, but this is not really good: it's not "clear" to an average user, and the files and code are apparent (which could be "dangerous" if the user edits or deletes them by accident).
So I was wondering: is there a kind of format that would makes me able to store the files of the app in a packaged file?
The file would be something like a .zip file, but when you click to the file, instead of opening up the archive, it opens the /index.html (or similar) which is inside.
So for the user, it would be similar to open an .exe or a single .html file, but still that's not a native app, as that's still a browser app.
Given that I know about:
Apache Cordova; but most of the time, I just use the browser functions, and I don't have a need to use advanced native functionalities;
UWP and PWA, but I don't know if it's exactly what I want (I imagine it as a mix of website and mobile app, but I'm surely wrong);
Open Web App (a standard from Mozilla), but based on what I've read about it, it seems deprecated and not used anymore. Plus, I don't really look forward to "certify" my app... I just want to package some files.

PWA I don't think is a solution to your problem as you wont be able to redistribute the code as an executable package.
UWP would be too Windows specific and might make you lose the platform independence that you already have since you are using plain HTML and JS, plus from what I understand you would need to distribute the app on Windows Store.
I believe packaging as an Electron app would be the best solution as you can provide executable files that can be executed in almost all platforms.

Electron would be the best solution for you. I had a client that first wanted to run app on php server and eventually they figured out they need it as a desktop app. It was easy to rewrite php stuff to node and package as Electron app. You have access to everything files, system etc. so you can do more if needed.
Another solution would be to just inline everything into a single html file.

Angular2 force/hard reload of browser cached scripts?

I know that there are a lot of posts about that in web, but none of them satisfied me.
Most of people recommends appending a verizon number to each script/css file. But this sound like a lot of job to me (project is qute bit), maybe there is some way to version only output files, some CLI command I dont know?
My solution was based of simple pinging to API for new version number, when > than stored then reload the page. And here is a tricky part - even location.reload(true) does not refresh the cached angular stuff. Manually CTRL+SHIFT+R does this job nicely. This would be good enough for me if the programmaticly hard reload would work.
I also tried a this.compiler.clearCache(); but also with no effect.
Thanks in advance! :)

The #angular/cli does the cache busting for you. It appends the hash to script/css file names if you run the ng build with the --prod flag.

EDIT: If you are using the angular-cli, the #Tomasz's answer is probably better than the methods listed below.
Ideally you would use a module bundler like Webpack or a task runner like Grunt to automatically 'fingerprint' your files (ie, append a unique identifier to the file name based on it's contents).
But if that is not an option, a simple hack would be to :
set the caching headers on your HTML to avoid caching on the browser
Append a random query parameter to your script tag URLs in your HTML which you can change each time you want a new version.
<script src='/js/some.js?v=1.1.3'></script>
Changing the random query parameter (v in the example) will ensure the browser makes a fresh request as the URL is different than the cached (older) version

Browserify bundles

Every time we release a new version of our software which is bundled using Browserify, we are finding that we need to ask our users to clear their cache using the regular methods of CTRL+F5 or diving into the browser settings. It is not ideal when there are a thousand or so users. We are trying to work out a way that we can perhaps get around this. I am open to all sorts of options.
Our project is ReactJS based, so runs in the browser and connects to back end services via a RESTful API. We do track which version is loaded and this is visible from within the console. Using the version number we can compare on two different machines that one user is running the latest version whereas someone else may not be.
The code is bundled into two separate files and I feel that this is where we should be looking.

You need to change the file name on each new release.
A hash of the file is an appropriate thing you could add.
Check out md5ify to add this to your project build.
If you implement this yourself, make sure to also load the correct filename in your index.html file.
Edit:
To automatically load the correct file you need to have a placeholder in your main html.
Then you need a manifest.json file that looks like following:
{
"main.js": "main.[HASH].js"
}
This has to be created automatically after the bundling.
Now you can replace the placeholder with correct asset by doing a lookup in the manifest file.
You either have to write your own scripts for this or use something like gulp together with browserify.
Another solution would be webpack

Best practice to maintain minified files and deployment/development

I'm stuck in a bit of dilemma on how to get around this and was hoping someone would point me in the right direction.
I am trying to cut down on the size of css and javascript files to improve our website's performance. But the problem is, on deployment, we simply upload our current svn repository's latest development version onto the server.
I am finding it hard to add that extra step for every developer to minify files before every change, as it adds a risk for negligence and human error.
I was thinking about having the readable version of files on the server anyway, but having some kind of file monitor that will execute a minifier when a file is changed, and update the file used by the website. Has anyone implemented this before?
EDIT
We're currently running on ASP.Net 2.0, Windows Server 2003

If you are using .net on the server, you could also try RequestReduce available on Nuget. It minies and bundles your css and js and also sprites css background images. It does it on the fly so your devs don't have to do this as an extra step. As long as you have some kind of versioning in place that changes the css/js url when it is changed, RequestReduce will automatically detect the change and process the file. It does all of this in the background and there fore does not affect the response time. If the files are not versioned via the url, RequestProduce provides a dashboard where you can flush its cache. RequestReduce can be deployed with absolutely no code changes and hardly any config in most use cases.

If you are using ASP.NET, try MBCompression library - it minify files automatically and you don't need do it manually:

Best practices for maintaining javascript libraries in repositories?

When developing javascript code, what are the best practices for maintaining the code in repositories?
For example, suppose I develop a set of useful functions and put them in a script called "sugar.js". In the code repository I put them in c:/codebase/suger.js.
Now I want to use the script in a web site being developed and I locate it at c:\mywebsite\sugar.js (ready for uploading to a server)
Do I keep a copy of sugar.js? What if I fix sugar.js in one location - it won't be synchronized with the other?
What if I build a second web site that also uses sugar.js? Do I take another copy located at, say, c:\mywebsite2\sugar.js?

If you are using something like visual studio, you can use NuGet for versioning many of the popular javascript frameworks on a per-project basis.
If you are writing in something else, you could try package managers such as npmjs or http://jspkg.com/JSPkg.
If it is your own library, I would recommend setting up source control and having versioned releases as branches or tags, that way you can keep track of everything. Git and GitHub support this type of thing, and you can set it up to have each version as a zipped download.
I would also try to keep each project's javascript files separate, that way any changes won't immediately break every site, just the one you recently updated. This advice could go out the window if you are running hundreds of sites and really just need a CDN.