I have an Angular 6 library which contains couple of modules with its routes. This library also works as a standalone application.
I have used ng-packagr to pack and publish the library. When packing all the dependencies included in package.json dependencies also gets shipped and is installed when consumed by an application.
This behaviour results in duplication of angular core libraries and app does not start.
One of ways i have handled is include all the dependencies as devDependencies in package.json, so they wont get shipped. Is there any better way to handle this without moving to dev dependencies ?
It looks like having dependencies as devDependencies is the solution for now, as having just peer dependencies works when inported as a library but it doesn't install deps when using in an application.
Related
I am creating an angular library, which is internally using the vtk.js library. I tried adding vtk.js as a peer dependency. But on installing my custom package, it is showing a warning to install vtk.js as well.
Is there any way I can make sure that the vtk.js package will also get packed inside my angular package?
You can express dependencies of your library in a 2 ways (actually 3 but devDependencies is pretty self-explained so we omit them)
peerDependencies - you can use this type of dependency if you need to express the following things:
Your library is depends on some specific version of another library
Your library will have a conflicts in case node_module contains few versions of the dependency (because of so called transitive dependency this case is possible)
You wish a developer decide on what version of the dependency to use
As you mentioned peerDependencies is not installed automatically, instead it will warn a consumer of you lib about missing dependency or incompatible version of it
2.dependencies - use dependencies if you do not care about the cases described above. Having vtk.js here guarantee that it will be installed automatically for every consumer of your lib
I have a Lerna powered monorepo which contains various packages that are published to NPM. Within this have various helper functions that live on the root of the repo and are shared by a few packages.
The issue I have is that when each package is built with Babel, the transpiled code uses require to get those helpers. Obviously this doesn't work as when a package is published it needs to be completely self contained - those helpers are not there.
Is there a way to solve this? I don't want to have to duplicate helpers between packages.
When using lerna bootstrap --hoist I still have the same issue.
Well the easiest solution i see is to create an helper workspace that you do not publish when using lerna publish.
You will be able to set this "helper" workspace as a dependency of each of your workspace, therefore avoiding code duplication.
I want to create a core NPM package that contains all dependencies which rarely change, e.g. Angular. Since different projects will use this NPM package and Webpack is the preferred bundling and build tool, I thought Webpack's DLL plugin would be a good choice.
But somehow the consumer packages cannot resolve the contents of the library package created with the DLL plugin. I've created a minimal example here https://github.com/matoilic/webpack-dll-example. The core module only contains Angular and the consumer module should then be able to use Angular from there. But the build of the consumer package fails with the error, that 'angular' could not be found.
Module not found: Error: Can't resolve 'angular' in '.../packages/poc-module/src/application'
Does anyone have an idea what the issue could be?
It seems like the DLL plugin doesn't handle symlinks properly. In my case, I have a mono-repo with multiple packages which are linked to each other.
https://github.com/webpack/webpack/issues/3489
The workaround is to create an installable package through npm pack and to install the resulting archive instead of using npm link.
Ember CLI applications have a package.json that lists everything as a dev dependency. Even stuff that is needed in the app's production version. For instance packages like ember and ember-data are installed as devdependencies.
As a reference, here's a sample of what I'm talking about: https://github.com/ember-cli/ember-new-output/blob/master/package.json#L17-L38
What's the reason for this?
In the context of application:
As #Lux mentioned in the comments, you don't need them after the build.
The output of the application is the build, that is supposed to be the final product. Further, you generally don't depend on another application. You generally depend on a package or an addon.
In the context of addons:
I think there is an opinion to display all of the addon dependencies of an application at the application's package.json file. By doing this way, you can prevent that an addon unintentially adds a js file to the build.
As a result, the ember way of managing dependencies is to leave all of your dependencies at your devDependencies and add all of the dependencies of the addon to the application's package.json with default blueprints. So the end user can tune them.
I am exploring AngularJS tutorial project and found it has node_modules directory inside, which size if 60 megabytes.
Does simple clientside javascript project really need so huge corpus of unknown data?
I tried to delete this directory and project still works. I suspect it somehow relates with node.js and it's npm but how? Suppose I need to run my project on some conventional web server (not node.js), then how to know, which files/directories are unneeded?
Many javascript libraries require to use bower to install them. If I use bower, does this mean I need to keep node_modules?
The node_modules directory is only for build tools.
The package.json file in the app root defines what libraries will be installed into node_modules when you run npm install.
Very often with an angular app, on your dev machine or on a build server, you use other Javascript libraries from npm (a node.js package manager) to build your angular app. Tasks can be concatenating resources, using CSS preprocessors like LESS or SASS, minification, replacing of values, etc. etc. The most common tools for managing and running these tasks are called grunt and gulp, which are installed through npm as well.
When you deploy your app, you only distribute the resulting build, not any of the source files or build tools.
It is of course possible to write an AngularJS app without building anything.
edit from comments: When you dive into Angular more, there are more advanced techniques of using libraries installed by npm even in the client app, you then selectively choose the ones you need, not the whole 50MB+ thing. I'd recommend staying with the basic approaches until you get a good grasp on them though.
NPM is the node package manager, which installs packages locally into a project, specifically, into the node_modules folder. From there the package code can be included into a project, yes, can is the important word there.
The browser has no way to include modules in code (yet), so you need to use a library that can expose node's commonJS style modules. Browserify and Webpack are two popular methods of doing so.
Angular complicates this by introducing its own module system, which more closely resembles AMD-style modules. There are ways around this, so that you can use node-style modules, maybe your project uses those.
Using npm for managing dependencies is a great idea, its a fantastic package manager. It is likely in your case though that the project is only built using node and that the node_modules folder contains dependencies only related to the build.