ESLint plugins follow a naming convention: eslint-plugin-horses
I'd like to publish a fork of an under-maintained ESLint plugin, but, if I change package name to eslint-plugin-DEVIN-horses then other ESLint plugins/configs referencing horses will need to now reference DEVIN-horses.
A core issue is that our company proxy does not allow packages to be installed directly from GitHub, otherwise, I'd be using this package.json dependency syntax:
"eslint-plugin-horses": "devinrhode2/eslint-plugin-horses#no-horse-shoes"
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
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)
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
When looking at this package.json I see two versions for sinonjs:
"dependencies": {
"#polymer/sinonjs": "^1.14.1",
...
"sinon": "^2.3.5",
...
},
What is the difference between sinon and #polymer/sinonjs?
Node packages that start with #namespace are scoped packages. Typically this means an organization that wants a standardized naming convention for all of their packages that might have common names already taken in the global namespace.
In your example the organization is Polymer who has their own published version of sinon. As to why Polymer has their own published package of Sinon you'd have to ask them. The description suggests it's a workaround to access the Bower version of Sinon. That workaround probably wont be needed once Polymer makes the jump to NPM.
SinonJS proxy repository for the BowerJS package manager
I have a multi-module maven project (maven 2.2.1).
One of the module is a maven plugin.
This plugin is bound to the compile phase of another module, and added as a direct dependency to trigger correct reactor ordering of module's building.
If I run 'mvn clean install' on the root module, with a fresh local repository, everything goes fine (build, test, install). (I precise that my project's artifacts are not deployed anywhere, only installed locally in my machine's local repo).
BUT if I delete my local repository, and perform 'mvn test', the plugin module is reported as missing ? Whereas, the build order is correct, the plugin module is built succesfully before the module using it ???
Is there any special treatment of maven module with 'maven-plugin' packaging ?
I don't understand why other project inter modules dependencies are resolved correctly and not this specific one !
The problem is that a Maven Plugin must be installed into the local repository first before you can use a plugin as a dependency (or better be part of the life-cycle).