One of the biggest obstacles for adoption of Angular in the enterprise is technical, but not of the nature that one could expect.
Its hard to convince our boss to use Angular in our next project if we can't even install it in our own PC ;-) ! We would probably want to do an early demo or prototype to get things started.
But many companies have corporate proxies and security policies that make tools like npm hard to try out for the first time.
One of the biggest features of AngularJs is that it does not come necessarily with all the tooling ecosystem, and can be used via simple script tags. Angular 2 and beyond in principle can also, but we really want to use it together with Typescript, the Angular CLI, Webpack and all the tooling ecosystem.
So how can we solve this ? Let's have a look at some tips and tricks that will likely help you get things going in this new world of node based tooling at your company.
Below you will find a video with some tips and tricks that you might want to have a look into.
Table of Contents
In this post we will cover the following topics:
- How to install node and npm on Windows without admin rights
- How to install a bash shell on Windows without admin rights
- switch easily between node versions without admin rights
- Dealing with corporate proxies - where to start
- Temporary configuration for Npm
- Dealing with corporate proxies: you might want to put another proxy in the middle
- Install Cntlm to interact with your corporate proxy
- Install Fiddler to interact with your corporate proxy
- The importance of having an in-house package manager
- The Npm enterprise package repository
Video version of this post
This is a video version of this post on YouTube, subscribe to my channel for more videos like this.
For the tool for switching node versions, you might want to look into nvm-windows instead of Nave:
How to install node and npm on Windows without admin rights
If you are installing node and don't have admin rights, at least a while ago this was not possible using the download link on their site.
This is because the installer tried to make an entry in the registry and this is typically forbidden in most companies. If this is still the case, or the npm website is blocked, you can still download node and npm as a zip file and install it manually.
For that, head over to the following url and download the version you need:
For tooling its better to download the latest version, and not the long term support version. Command line tools very quickly break with the long term support versions.
What tends to work best is to use the LTS only if we are running node as a server, and use the latest version for the command line tooling.
How to install a bash shell on Windows without admin rights
A great thing to have with node command line tools is a Bash shell, even if you are running on Windows. This is because like that you don't have to use one shell on the server and another on your PC, so less things to install and commands to keep in mind.
Also if you like to use NPM scripts, its great to be able to use some shell commands if needed. For more complex builds we want to look into Webpack or Gulp but for certain things its great to have Bash around.
A bash shell that you can install in Windows with no admin rights is Git Bash, available together with the overall installation of Git:
This is not mandatory but its a great thing to have when using npm, and a good way of building npm scripts that work both on the server and on a developers PC. If you go that route then everyone on the team would need to have Git bash installed.
Note that during installation, there is a checkbox for integrating Git Bash with Windows explorer. This is to right click on Windows Explorer and be able to do Git commits.
You can still install Gitbash without admin rights, but you will have to make sure that checkbox is unchecked.
Switch easily between node versions without admin rights
Once we have node, npm and a Bash shell running in our machine, we want to have a way to quickly switch and upgrade between node versions.
There are a couple of tools that we could use to do that: nave and nvm.
There is also a windows version of nvm called [nvm-windows](
https://github.com/coreybutler/nvm-windows). According to the nave docs:
nvm has to be sourced rather than being run, and thus is a little bit wonky for some use cases. But it doesn't involve subshells, which makes it better for some others
You will probably want to go with nvm-windows, these are the main commands:
# install node version nvm install 7.2.0 # show available versions of node nvm list # switch to node version nvm use 6.9.0
With this we have node, npm and a bash shell ready to go. But if we run npm install of a package, we will probably at this stage get an installation failure due to network connectivity issues.
Dealing with corporate proxies - where to start
The best place to start troubleshooting connectivity is to see if you can access the npm registry in your browser. Head over to this url, can you see some content or does the proxy block it ?
Plus some packages are downloaded straight from Github. You will want to see if you can access Github as well, without that you will run into issues eventually as certain packages will not installable without Github access.
If you have proxy credentials to access the internet, let's at this stage add them to the configuration of npm.
Temporary configuration for Npm
Depending on your company security policies and if they are proxying HTTPS as well (this is done in a lot of banks for example by introducing a self-signed certificate in the browsers of your company computer), you might run into HTTPS issues.
Have a look at the certificate chain for google.com for example. If you find the name of your company in the certificate chain, you are being HTTPS man-in-the-middled ;-)
In an initial stage and to develop a prototype, you might want to go HTTP only temporarily:
npm config set registry "http://registry.npmjs.org/" npm config set strict-ssl false npm config set proxy <http only proxy config url> npm config set https-proxy <http only proxy config url>
If you don't know the proxy coordinates, it might be the same as your Windows PC user and password, or email and password, in case a single sign on system is in place.
It's better if in doubt to ask a proxy user for these purposes to the IT infrastructure team.
Consequences of turning off HTTPS
This is important to be done temporarily, while a better long term solution is not in place. On the long term this would open up your build system to malicious code injection.
We will see further how to avoid that and make sure we are running the right code in production, but having a working HTTPS connection towards the npm registry is essential for that to work.
Dealing with corporate proxies: you might want to put another proxy in the middle
If your corporate is blocking requests, it might be that your open source tool does not work with that particular proxy. Windows proxies are notoriously hard to get working with open source tools.
A solution for that might be to run a development proxy in your computer, that connects to the corporate proxy. A development proxy is a good tool to have in our toolbelt as it helps troubleshoot all sorts of other problems as well, sometimes we need more than the Chrome Dev tools network tab although its rare.
Install Cntlm to interact with your corporate proxy
A very minimal development proxy that works well with Windows proxies is Cntml. So one option is to use your windows credentials to connect to the Windows proxy, and connect your tools to Cntlm.
Install Fiddler to interact with your corporate proxy
Cntml is a great tool but its only a small process with a config and a log file. Another development proxy that comes with a great UI as well is Fiddler.
The importance of having an in-house package manager
As the project evolves, we will end up needing an in house package manager. This serves several purposes:
- we want to be able to cache packages at the level of our organization, so that our builds don't break if there is a problem with the npm central repository
- a while ago someone deleted a package called left-pad from npm and broke a lot of things. This is unlikely to happen, still it would be better to avoid this by caching all your packages at a local company repository
- we want to cache the packages locally so that the builds are faster
- we might want to put range version restrictions in certain libraries
- we might want to validate the signatures of certain libraries that are downloaded into our build system
The Npm enterprise package repository
We can have an in-house version of the official npm repository running in our own company, in case using an external repository is not an option which is often the case.
Npm enterprise is an in-house self-hosted version of npm, it uses CouchDB as a persistence mechanism.
Given enough time, companies will adapt and allow for exceptions for this new type of network intensive tooling like npm to be used by development teams. But this could take years on some organizations.