How do you manage versioning of dependencies, in nodejs? - angularjs

We've been a Windows shop, mainly relying on Visual Studio as our IDE and build tool. We've begun to explore using Angular and node, and angular-cli.
We have a project that depends upon "angular-cli": "1.0.0-beta.10". I was trying to get this to build on a new machine.
I installed nodejs, then did a global install of angular-cli using npm:
npm install -g angular-cli
Then I tried to do a build:
ng build
I got an error:
It seems like you're using a project generated using an old version of the Angular CLI.
The latest CLI now uses webpack and has a lot of improvements including a simpler
workflow, a faster build, and smaller bundles.
To get more info, including a step-by-step guide to upgrade the CLI, follow this link:
https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14
What I did to get things working was to uninstall angular-cli, and then install version beta.10
npm uninstall -g angular-cli
npm install -g angular-cli#1.0.0-beta.10
After that, things work just fine.
Unfortunately, that's not a solution.
We will, eventually, have multiple projects using node packages, we need them to be able to run simultaneously, without having to uninstall and reinstall global packages.
And we need to be able to run builds automatically on our build machines, without having to RDP into the build machines to mess about with which node packages are installed.
That is, if I have three projects that use angular-cli#1.0.0-beta.10, I expect all three to work on any of the developers machines, and that the build machines will be able to check out any of the three projects and successfully build them.
And if I update one to use beta-12, and another to use beta-14, I expect to be able to commit them to version control, and for the build machine to be able to check out any of three and still be able to build them, regardless of which version they use.
I thought the whole idea of tracking local dependencies in package.json, and storing local copies in node_modules was to avoid dependencies on globally installed packages.
How do people usually manage this issue?
Is there a way I can configure angular-cli so it doesn't depend upon a global install?
Are there other packages with which I'm likely to encounter similar problems? Is there an approach that will work for any of them?

The Angular-CLI can be run with, and the global ng command uses, a locally installed version for each project. This local version can be accessed using the command ./node_modules/.bin/ng
I recommend uninstalling the global CLI you have and taking the time to modify your package.json scripts to reference the local CLI installation rather than the global ng. This is my method to handle varied CLIs on my Jenkins server.
On that note, I do highly suggest following the instructions to move from Beta.10 to Beta.14 (https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14) if you can stomach the change to WebPack. Any projects utilizing CLI Beta.14 or higher can be upgraded to the latest beta simply by uninstalling the CLI, reinstalling it, and then running ng init (Diff [d] any files you've modified!) to update the boilerplate.

Copy & Paste the typescript components html's and css/scss files to a new build, it's not even worth it to mess with the core build of those stuff.
Bear in mind that you might see imports being grayed and the same very imports to be needed to add in app.module.ts as its a core file nowadays to every single project of ours.

Related

How to link NPM pacakge locally to remove dependence on remote?

I am building a react project for which I am using a 3rd party library. The library is available as an npm package, which solves the purpose. But the package is unreliable as it has very few downloads and not updated in years. I am trying to use it as a local package instead of a remote one. I npm installed it, but cant figure out to link it locally.
Note: I searched for other well maintained packages, but couldn't find one & I had to stick to this one.

ReactJs Library that installs globally

I'm wanting to create a React library that I can build locally and that deploys into the NPM global area. I want to be able to use my other React project that also sits on my machine and picks up changes as I modify the library. I have found plenty of tutorials that either deploy to NPM (which I don't want) or that I have no idea how to get it updating automatically to my project. I tried one with rollup.js that seemed to work for a while but then stopped for some reason.
Ideally looking for tutorial or source code that I can look at.
Do's: build locally, automatically update changes to my project
Don'ts: deploy to NPM or another external repository, cause problems when setup on another machine
Want: One library, one project, easy update to the project when the library is changed, be able to create an entry in the global install with the library version
Thanks
Paul

create-react-app taking up too much disk space and time

It's my first experience with react and as stated in official docs, I was trying out create-react-app to create my first react app.
But I notice that it takes around 15-20 minutes to get finished( even though I have good internet connection) and once it was completed, I noticed the space taken by the newly created folder to be around 165-170 MB.
Isn't there any quicker way to get started with react as the above mentioned method probably installs some modules that are never going to be used.
Thank You.
I also faced the same problem when i first started learning react. What i did was i manually configured webpack to bundle my code. And then i created central node_modules folder in particular place. So anytime i want start a react project i just create a symlink to the node_modules folder. And also if i want install a new package, i go the central folder and install it, so the package will be available in the node_modules folder and for any of my project that may need it. That way i only need to install a package once not every time i want to use it for a new project.
But recently i found a package manager called pnpm. Instead of downloading a package anytime need to install it, pnpm maintains a central cache of packages such that anytime you want to install a package, it just creates a symlink(or junction in windows) (similar to what i used to do).
Conclusion
In conclusion i would recommend you to just configure a bundler (vite is cool) by yourself and use pnpm to install packages. You can read more about pnpm on there website

Is there an official nuget package for Angular 2?

I'm currently working in a work environment where I do not have access to npm / node. The npm download location is actually blocked so I can't get any packages.
I want to build an Angular 2 site. As I can't access npm, I want to use Nuget to get the files. Although I can see the Angular 1 packages, I cannot seem to see any Angular 2 packages. Is there one for Nuget?
Also, is populating the node_module folder and compiling the Typescript the only thing that npm does for Angular? If I can just get a copy of the node_module folder (from outside work) and get TypeScript working in my solution, can I basically bypass the need for npm?
In short; No.
You can see a list of all available NuGet package versions here, with the most recent being 1.5.3.
Even performing a generic search shows most recent versions as 1.5.3.
Sometimes they'll have beta versions of packages available that you can install with a command similar to: Install-Package EntityFramework -Version 6.1.3-beta1 -Pre, but it doesn't appear as if they have created any pre-release packages.
So, as #Michal Dymel mentioned, you could get it from a CDN or some other location.

How to create new app projects without downloading and installing npm modules again and again? [duplicate]

This question already has answers here:
How can I make multiple projects share node_modules directory?
(7 answers)
Closed 4 years ago.
I've installed most of the NPM modules globally with -g
However, I see that whenever I create a new app project (example: angular project) using Yeoman, I see that the npm modules get downloaded again and get installed in the local node_modules folder.
I consider that this is extremely wasteful that the same modules gets downloaded and copied for each new project. The size of each new project is then around 160MB.
Is there a way to download only the modules locally in the new project that are not already available in the global npm node_modules folder? Say, anyway to automatically create symbolic links from the local node_modules folder to the globally installed npm modules?
Is this possible? How to set it up?
This is actually by design. From the Node.js blog:
In general, the rule of thumb is:
1.If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.
2.If you’re installing something that you want to use in your shell, on the command line or something, install it globally, so that its binaries end up in your PATH environment variable.
it is important for you to install project dependencies locally, as you have no guarantee that what is installed globally on your machine may be available on the deployment machine. True, you may manage both machines, or they may in fact be the same machine, but that case is never guaranteed.
Also, it's not unusual for you to have projects which rely upon a specific version of an npm which you may have installed an update for globally, breaking the project that needed the older version. Isolation is a key to keeping projects functional.
if you REALLY need to only maintain one copy, you can use symlinks. npm link globalnpm
Install it globally, and then npm link coffee-script or npm link express (if you’re on a platform that supports symbolic links.) Then you only need to update the global copy to update all the symlinks as well.
Note that the symlink option is really only relevant for hand initialized projects; generators such as Yeoman will always use local, as they follow the grain.
There are workarounds, but this is intentional to avoid equivalent to DLL hell or specifically library versioning mismatch meltdown. Besides 160 MB is a tiny price to pay for this luxury. Discrete functioning bundles are much nicer to ship as a unit of goodness - trust me

Resources