So that would be great if they were indeed added into my packages, but it seems that they are not.

OK, I was supposing it but I didn't find it explicitly in documentation. Thanks for your quicker answer.

Here is a solution for you guys : We implemented two open source tools that allow using bower package-based artifacts based on Alana's previous comment. They are still in active early development, but we are currently using them in our day to day work. ##Bower client https://github.com/WoltersKluwerCanada/proget-universal-bower-client This tool is packaging bower repositories into a .upack file It can also deploy to a proget repository ##Bower resolver https://github.com/WoltersKluwerCanada/proget-universal-bower-resolver This tool is an extension to bower which resolves/unpackages upack-proget feeds as bower feeds.

You can install a separate website in IIS that points to the same home directory, which supports forms authentication, then use that separate URL for npm & bower. With a separate IIS site, upgrading won't touch it so it will upgrade as per normal with the installer.

There currently is no transform for this and it's unlikely we will add one.

This is correct, bower packages are not packages but simply URLs that point to a git repo. The git repo is the "source" of the package so without continually syncing the entire git repo it wouldn't be very useful. We may in the future add this (so no outside repos are requested similar to npm's and maven's indexing), but it's a ways off.

HTTPS/Certificates are at the socket layer... below ProGet's application layer. We're not familiar enough with Bower's internals, but it's most likely just using the operating system's network stack, and reporting warnings/errors from the underlying components. Likely it's a certificate trust issue between your computer and the ProGet server, or some intermediate authority. So, while there's nothing we can do on the PRoGet side, hopefully this helps point you in the right direction.