I understand that packages hold several modules, but I'm starting to get confused as to if packages and modules are dependencies. Also, libraries to me maybe seem like packages you install via NPM, Nuget, RubyGems, Bower, Homebrew, or Chocolatey. So are libraries packages? Dependencies are something you need to load within your application, to have a certain functionality, but aren't some libraries(jQuery) seen as a dependency? So yea, what are the differences between these concepts?
Libraries are just a bunch of code anyone can use. For example, React.js is a JavaScript library for building front end components.
If I decide to use this library in my app, then React will become one of the modules (aka an installed instance of the library) that my app depends on. So dependencies are pretty much all of the libraries your app depends on, in order to run the way you expect it to run.
I asked the same question you did about dependencies, and I learned that it's a matter of understanding how these terms relate to one another rather than finding isolated definitions for each of them.
Hope this helps!
Basically a package is a pack with some features which fullfills some functionality of your app.
Once you install any package using npm then the package is installed as a dependency in your app inside your package.json file along with its modules(aka libraries consist of classes) stored inside node_modules folder.
I hope its clear now.
Related
Recently I started to use a private npm packages for backend.
They stored on our private packages server (an npm repository I deployed among application components.
And while I mostly like how it all works and happens, but there is a gotcha.
Imagine a packages like:
#example/logging, #example/utilities, #example/validation, #example/database, #example/security - low-level packages. And many of these low-level packages depends on #selfcad/logging package.
#example/updates-queue, #example/subscriptions, #example/auth-tools, #example/cloud-functions and #example/backend-core packages are representing high-level abstractions and components. Each of high-level packages depending on few or sometimes all of low-level packages.
Some of these packages are referenced in cloud functions via #example/cloud-functions package, especially low-level packages. Other used directly in a cloud functions.
Plus there is a backend component where most of packages are used directly.
So, true headache starts, when a change must be made e. g. in the low-level package like #example/logging or #example/validation.
And what is the most easier way to spread the update or fix to widely referenced lower package? With nested dependencies.
Like so: a package, e. g. #example/validation referenced directly and indirectly, like #example/configuration uses #example/validation, #example/database uses #example/validation and I updated #example/validation internals. How to spread such update across packages?
Maybe you should have a look to Yarn Workspaces. This is a useful feature of yarn to link dependent packages each others using a mono repo. This feature also includes auto-discovery/auto-linking.
I'm just starting to learn Angular, I installed in my Ubuntu Linux:
Angular CLI: 7.1.4. and
Node: 10.14.2.
My question is, why one project is too large? I mean a simple "helloworld" is 334MB, I don't know why, Is it possible resize it? or delete any folder that is unnecessary? Or Is there something wrong with my installation? (how can I detect that?)
The bigger folder is node_modules, and when I create my projects, generates a lot of folders.
I was reading about "angular lazy loading", but I'm new.. It is not totally clear for me.
this is the folder spaces:
Please... I hope somebody can help me...
best regards
You might be using big bundles which are not needed, so you can break them up:
https://medium.com/#julienetienne/javascript-bundles-are-too-big-break-up-the-libraries-3be87d5ef487
In modern JavaScript, projects require modules that themselves require modules that require modules... resulting in node_modules directory with hundreds of dependencies. A 100Kb library might be included because someone needed one function from it. JavaScript is not compiled, so all that source tends to be rather big. This is an unfortunate, but unavoidable truth; your Angular project directories will be big, and there's nothing you can do about it. It is perfectly normal.
The good part: modern JavaScript deployment typically includes packing up those libraries with Webpack or Parcel or similar code bundlers. Most of them implement "tree shaking", which analyses the code to find only the functions that are potentially utilised starting from the entry point, and only bundle those, ignoring the rest. This means that 100Kb library whose one function is used is transformed into just that one function in the final distribution bundle.
Not all of the bundlers are equally good at it at this point. For example, Webpack cannot tree-shake the CommonJS modules, only ES6 ones.
You can remove node_modules folder when you are not going to use the app.
And, when you need work on the application, you can re-generate node_modules using the command: npm install
Those are just node-modules, they are needed for building the project, but not necessarily everything inside of them will be deployed to production. As Amadan said, there is a process of tree-shaking (filtering only used modules) and also in production you use the minified version of the same JS code (where for example whitespace is missing and variable-names are shortened), among other optimizations. A production-optimized Angular project should not be more than a 100KB for a hello-world application.
In the provided image I see packages like
selenium-webdriver
protractor
Those belong to dev-dependencies (see your package.json file) because they are used for testing. When building for production, no code from dev-dependencies should be included. The typescript package (which is nr.2 in size in your screenshot) will also not be present in production because types like string are only used for writing Typescript code, but the browser receives Javascript, which it is compiled to.
I've built a custom style "skin" on top of bootstrap that I intend to use in multiple UI projects.
Rather than copying/pasting the UI styles/components (built using sass and typescript in my current Angular 5 project), I want to build an NPM package that I can install these styles and components I've built in new projects, thus allowing updates to be done to the NPM package (maybe extending the controls within for example) without breaking the UI's using them or needing to update files within.
I've never setup an NPM project before. I've found a number of examples of how to build NPM packages, for example https://codeforgeek.com/2014/08/how-to-create-nodejs-npm-package/ but it seems to be for vanilla JS in this example. I need an example which:
Builds on a dependency, in this case bootstrap
Is to be used in Angular (I'm using version 5)
Is installable and updatable via NPM or maybe Yarn
Has anyone any top tips on achieving the above? Or any really clear guides where someone has done this before?
I realise this question is relatively broad but really I just need some pointers to get started and I will document the process further when I have a better understanding.
Thanks in advance!
So you should move your theme into a separate project. Then all you have to do is run npm init in that directory and you have a npm.
As for sharing it between projects, I would create a repo on Github for this theme npm. Push all of your changes there. Then you can reference it in the package.json of all your projects by linking to the Github repo. Here is a good Stack question about how to do that.
Finally, if you want to develop your theme locally inside one of your projects, you can use npm link. Here are he docs on that.
I am new to angular2 and I have never used angular1.
I have been trying this tutorial https://angular.io/guide/quickstart and
i wonder if all the recommended dependencies are really necessary because my project size gets big after 'npm install' (more than 100Mb).
You won't necessarily use all of the #angular dependencies during the Quickstart, but if you continue on with their tutorial and as your app gets more complex, you will definitely utilize them.
The other packages are necessary. They consist of typescript compilers, libraries for Observables, and more Angular 2 features. Here is a quick read for info on some of these.
If you're using angular-cli, calling ng serve will also run a series of automated tests that depend on packages.
Practically speaking, are these essentially synonymous? Or is there something I'm missing? I've use Composer (PHP), CocoaPods (Objective-C), and Bundler (Rails). I believe they describe themselves as dependency managers but can they also be consider as package mangers?
I'd say yes. Given that the javascript community calls their version of those tools (NPM and bower) "package managers", I think that the development community has essentially synonymized those terms.
EDIT I'm going to backtrack a bit. In general, I think the term package manager has to do with the delivery and installation of third party code. That said, npm is correctly named the node package manager. As I see it, a dependency manager is a different thing. It's an runtime orchestration tool. For example, there are dependency managers that simply run in the browser to load asset files in the proper order (think requireJS, browserify, cartero, etc... - or think a Dependency Injection container in say Symfony2 or Laravel) but you wouldn't call those package managers. A package manager would be something like Debian's dpkg or the node community's bower, which actually downloads third party libraries for you (that aren't currently in your software suite). Now, I think the burred lines come in when package managers decided to be smart enough to resolve version numbers for us. Because tools like npm make sure that each piece of software we declare has all of the proper versions of it's dependencies (by downloading a chain of dependencies for us), we want to call it a dependency manager. But I think it's more proper to say that it's a package manager that happens to do version resolution. It's really more of a delivery mechanism than a runtime tool, though.
All that to say, I'd like to hear what others have to say about this.
No, they are not synonyms. Look At that answer for their difference
https://stackoverflow.com/a/27290095/4016254