Why is root involved? NPM can be installed and used without requiring root.
The issue comes in to play because NPM makes packages available as commands in the system by by PATH. Perhaps they should change this and provide instructions on how to modify PATH to include the bin directory node creates when users install packages globally. At the least, it would have been half-way responsible to craft an installer that does all the setup work for users, requiring root once to run the script that adds PATH vars and install to a specific user.
Glad I contained this beast in its own Docker when the need for it arises. I'll expand on this if anyone needs help setting this up and understanding how to containerize things like this (or PHP, fucking python, or any other crap-all-over-the-place RE/PM/etc.) in project tooling or single-use containers. Other tools can be containerized as well; I use docker for Chrome too, which is especially useful when each client gives me a google user for their org and an integrated SSO like Okta which requires a browser plugin.
This is an important bit of advice to take note of. Corporate history is a great way to establish context for IT needs and can be incredibly valuable as you don't have to go far to establish the "why" in decisions that had lead to the current implementation of technology in your company. The current deployment and strategy may or may not be correct, but the context is important for using as a launching point for change, if needed.
In my experience, technology is only part of the value of IT. Chances are, your company's main economic engine is not the ability of the IT department. Twice I have shifted IT departments which serve the company only to ITSM and focused on service strategy, delivery, and design to improve service maturity. The wealth of experience of these workers is a valuable tool to improving your outcome whilst implementing a strategy. Using the guidelines of ITSM (such as ITIL), to any degree, will not only leverage these workers' collective knowledge, but also begin to transfer their knowledge to a service manual, which can be used to remove burden of their day-to-day so they can begin to focus on other areas.
As your department concentrates their knowledge into a structured asset to the company, areas of need will become apparent.. As these needs become apparent (e.g. MDM for OSX computers which leverages a source of truth like AD or an SSO/federated system like Okta) , I find workers naturally pick up where the current knowledge ends and learn new skills commensurate to the need at hand.
If this type of self-motivation fails, an AC had an excellent idea as well; shift those who don't want to self-start to L1. If you do have a path to service maturity within a framework, such as ITIL or COBIT, L1 will have concrete requirements and plenty of work as they are the frontline to most problems or service changes.
In all, consider the blessing of having well-established members of your team. I've done disaster recoveries wherein a CFO couldn't understand the value driver of IT, shit canned the department, then hired me to rebuild a department under considerable cost constraints with no legacy knowledge.
Slashdot Mirror
This is an important bit of advice to take note of. Corporate history is a great way to establish context for IT needs and can be incredibly valuable as you don't have to go far to establish the "why" in decisions that had lead to the current implementation of technology in your company. The current deployment and strategy may or may not be correct, but the context is important for using as a launching point for change, if needed.
In my experience, technology is only part of the value of IT. Chances are, your company's main economic engine is not the ability of the IT department. Twice I have shifted IT departments which serve the company only to ITSM and focused on service strategy, delivery, and design to improve service maturity. The wealth of experience of these workers is a valuable tool to improving your outcome whilst implementing a strategy. Using the guidelines of ITSM (such as ITIL), to any degree, will not only leverage these workers' collective knowledge, but also begin to transfer their knowledge to a service manual, which can be used to remove burden of their day-to-day so they can begin to focus on other areas.
As your department concentrates their knowledge into a structured asset to the company, areas of need will become apparent.. As these needs become apparent (e.g. MDM for OSX computers which leverages a source of truth like AD or an SSO /federated system like Okta) , I find workers naturally pick up where the current knowledge ends and learn new skills commensurate to the need at hand.
If this type of self-motivation fails, an AC had an excellent idea as well; shift those who don't want to self-start to L1. If you do have a path to service maturity within a framework, such as ITIL or COBIT, L1 will have concrete requirements and plenty of work as they are the frontline to most problems or service changes.
In all, consider the blessing of having well-established members of your team. I've done disaster recoveries wherein a CFO couldn't understand the value driver of IT, shit canned the department, then hired me to rebuild a department under considerable cost constraints with no legacy knowledge.