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
Related
I'm seeing some API drift between the type declarations/definitions of a typescript DefinitelyTyped module (e.g. #types/prompts) and the javascript module it is meant to 'wrap'. How is one supposed to correctly pair versions for the the types package, and the version for the underlying javascript package?
Say I add a dependency on #types/prompts": "^2.0.14" in my package.json. How do I make sure I get the right version of javascript npm package that goes with it?
The npm package #types/prompts has no explicit dependency on the javascript module in its package.json, and there doesn't seem to be any mention of compatibility that I can see in the README.
All I've found is a loose comment in #types/prompts's index.d.ts mentioning:
// Type definitions for prompts 2.0
// Project: https://github.com/terkelg/prompts
...
Is there a convention we're supposed to follow? I'd be interested in hearing about a general approach, not necessarily just for this example.
References:
typescript types package: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/prompts
upstream javascript module: https://github.com/terkelg/prompts
In my experience, usually major and minor versions are being kept in sync between the upstream package and its #types package. Then the patch version would not match, due to the need of being able to fix a bug.
An example with react:
The current version of react is 17.0.2
The current version of #types/react is 17.0.37
The only part which isn't super clear is when a patch of the upstream package changes types. Is that change already applied in the types package?
So for example react decides to publish 17.0.3 which contains a non-breaking difference in types. How do we know if 17.0.37 includes that change? But for that, it's probably a better idea for react to actually publish 17.1.0 to address that new change.
I have installed a library and now I want to install another library which is based on that one. I'm not sure which of the following will happen:
shared library will be installed once, second library will use this one for its purposes.
I'll have two copies of the same library and ultimately a larger bundle
You'll have two copies of the same library and ultimately a larger bundle
Many libraries do peer dependencies for relatively big libraries (EG: react). So you can use a later version but npm will warn you there might be potential incompatibilities.
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.
I am building an NPM module for modals.
I want to use a heavy weight UI package named material-ui. Most of my projects already have it so I would like the package.json to follow this logic:
check if package already available
available? good - don't install it
not available? install it
I know that peerDependencies looks for existing packages which is good in the case my project has it. What happens if I put the package in dependencies? Does it always get installed or does it depends on whether it already exists? does it depend on versioning? are there any good options here? Clearly I would like to avoid complicated installation instructions like:
npm install modal-package
if your project doesn't have material-ui:
npm install material-ui#^0.17.1
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.