We have a monorepo using lerna and yarn workspaces. Multiple teams contribute packages to it and there are some common dependencies where we want to force people to use the same version.
What are the options to force all packages to use the same version of specific dependencies? Is there a way to achieve that without writing custom scripts?
I want to prevent this situation:
my-repo/
packages/
pkg-A/
package.json
"address-validator": 1.1.0
pkg-B/
package.json
"address-validator": 1.2.0
I know you can use lerna add or lerna run to add / upgrade in unison, but how to prevent an individual from unknowingly making their package unique?
I just noticed one nice solution to this problem in facebook's create-react-app. They import (all?) external dependencies in the react-dev-utils package and export them from there. Then all the other packages, like react-scripts, import dependencies from react-dev-utils.
This is nice because you only need to worry about using the latest version of one package (e.g. react-dev-utils) in order to use the latest version of all of the things you want to control. Also, it's flexible because you can override one of the dependencies by importing a different version directly.
So it could look like:
my-repo/
packages/
my-deps/
pkg1.js // <--- module.exports = require("pkg1");
package.json
"pkg1": 1.2.0
foo/
index.js // <--- const pkg1 = require("my-deps/pkg1")
package.json
"my-deps": 1.1.0
Related
The Webpack/Vue ecosystem is a very fragile one, with minor updates to loaders regularly breaking the build. It's basically a dedicated job to curate a working Webpack config together with a list of the exact dependency versions that are needed to make it work.
This Webpack config can easily be kept in a repository and then copied to many different projects and imported in their local webpack.config.js because webpack.config.js is just Javascript.
I'd like to do the same thing with package.json, i.e. have the curated list of dependencies in a separate file and when running npm install have them added to any other dependencies a project might have.
Do npm or yarn or any other external tools offer such a functionality?
Are you specifically trying to use a js file? If so, I don't have an answer, but if json is enough, you can just make an node package that just has the dependencies you want in it. Someone that includes your package will then pull in all the dependencies listed in your package because npm pulls in the dependencies of a project's dependencies.
Also see https://stackoverflow.com/a/55483109/14144258
If I need any dependency I use them under dependencies like this
dependencies:
flutter:
sdk: flutter
provider: ^3.2.0
http: ^0.12.0+3
get_it: ^3.1.0
connectivity: ^0.4.6
email_validator: ^1.0.4
shared_preferences: ^0.5.4+8
google_maps_flutter: ^0.5.21+14
When I can use packages uder dev_dependencies? I don't know what I have to see in the packages so that I can decide which dependency goes to which category.
dev_dependencies:
Pub supports two flavors of dependencies: regular dependencies and dev_dependencies. Dev dependencies differ from regular dependencies in that dev_dependencies of packages you depend on are ignored.
For Example:
If you are developing a package, and you want some packages which are only imported for testing purpose and not the actual implementation, then such packages should go under dev_dependencies. When you are importing a package, pub gets every package that your imported package depends on. Since pub ignores dev_dependencies, the packages which were used for testing won't be fetched by pub.
When using the ui you have the option of installing dependencies and plugins.
I am confused about the difference between both of these.
For instance, I can install axios as a dependency and a plugin.
Do I need to do both? Why do one over the other?
My current understanding is that dependency is just that, it adds a package to your project while a plugin will add configuration as well.
Am I correct in thinking that?
A plugin is exactly what you described. It 'plugs into' another piece of software and adds functionality. A dependency on the other hand means that your software simply depends on something to function correctly - usually code.
In your axios example:
The axios plugin installs another prototype property on your Vue instance (this.$axios.. or whatever it is called) so it definitely adds a feature to Vue.
You could also only use Axios by itself and import it in the files you need
import axios from 'axios'. You don't add any feature to Vue itself - you just use another software within your app. Axios here is a dependency.
I will probably not be completely correct, but my understanding is
Plugins vs Dependencies
Command line
dependencies are installed via the command line as npm install <name> or npm install --save <name> to add the dependency to package.json
plugins are installed via the command line as vue add #scope/vue-cli-plugin-<name> or with the shorthand vue add #scope/<name>
Installation
dependencies are placed into your projects node_modules folder
plugins will invoke the generator.js script of the plugin being installed. This generator.js may add dependencies to package.json, add import statements to files in your project, add/alter existing components, or any of the various things listed under the generator api docs
Usage
dependencies will need to be imported into any file you use them in, or imported globally, before they are able to be used
plugins often will have already set up global imports, making them available in every file. Plugins will also often add additional scripts to package.json (which show up as tasks in the vue ui)
My project depends on angular2 beta.6 and another project that depends on angular2 beta.0.
package.json for my project
"dependencies": {
"angular2": "2.0.0-beta.6",
"another-project": "0.0.1"
}
package.json for another-project
"dependencies": {
"angular2": "2.0.0-beta.0",
}
When I npm install my project, it installs angular2 twice:
node_modules/angular2 (beta.6)
node_modules/another-project/angular2 (beta.0)
Trying to understand how npm3 decides to nest angular2 beta.0. Is it because both are called angular2 and hence they can not both sit at the top level?
Trying to understand how npm3 decides to nest angular2 beta.0. Is it because both are called angular2 and hence they can not both sit at the top level?
Yes, this is correct. Node code require's a module by name, using code like this:
require('angular2');
Node itself is not aware of the different versions, that's the job of npm, so it just uses whatever module matches in the require path first, relying on matching directory names.
npm accommodates this by installing specific versions in directories for each module when a conflict occurs, so that the require path will include that first.
Yes, it is because of the beta.0. Because npm has found another version of angular2 on the global level, it will install it locally.
npm3 will install globally dependencies only if there is no other versions of the dependencies on a higher level.
Here is a little example I've found :
[node_modules]
dep A v1.0
dep B v1.0
dep A v1.0 (uses root version)
dep C v1.0
dep A v2.0 (this version is different from the root version, so it will be an nested installation)
Flat dependencies were introduced in npm v3. The documentation can be found here https://docs.npmjs.com/how-npm-works/npm3.
To answer your question from the docs
However, since B v1.0 is already a top-level dep, we cannot install B v2.0 as a top level dependency. npm v3 handles this by defaulting to npm v2 behavior and nesting the new, different, module B version dependency under the module that requires it -- in this case, module C.
So order matters. The module you install first will get it's dependency on the top level. Subsequent modules will have nested dependencies.
you can run npm dedupe to remove nested module dependencies if they exist in the top level.
I'm dependending on a library that publishes different module packages to npm (commonjs, ES2015, UMD bundles..) and specifies commonjs/index.js as the main point of the application.
However, I need my app to use the UMD bundle instead so I would need it to be bundles/index.umd.js instead.
I figured I could do this by looking into installed 'node_modules' and changing it directly in the package.json of downloaded library, but thats a very hacky thing to do.
Is there some other way of chanding the main file for the dependency?