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
Related
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"
I disovered the hard way today that I need to split a library into two packages; lets call them CoreLib and TestCoreLib. The CoreLib package is a library, the TestCoreLib library is the bundle of utilities and actors needs to setup the test environment required to test the CoreLib library. The added benefit of splitting this into two packages is that apps built with CoreLib can also beneift from use of TestCoreLib as it also suffices as a mocking library.
As TestCoreLib uses some actors from CoreLib, I defined CoreLib as a peerDependency of TestCoreLib.
{
"name": "TestCoreLib",
"version": "1.0.0-rc.1",
"type": "module",
"peerDependencies": {
"CoreLib": "^1.0.0-rc.0"
}
}
Conversely, I defined TestCoreLib as a devDependency of CoreLib as CoreLib of course has the need of passing its tests before publish.
{
"name": "CoreLib",
"version": "1.0.0-rc.1",
"type": "module",
"devDependencies": {
"TestCoreLib": "^1.0.0-rc.0"
}
}
Both release candidate packages have been published to NPM successfully and I have setup a third project DemoApp that uses both CoreLib and TestCoreLib successfully.
{
"name": "DemoApp",
"version": "1.0.0-rc.1",
"type": "module",
"devDependencies": {
"CoreLib": "^1.0.0-rc.0",
"TestCoreLib": "^1.0.0-rc.0"
}
}
The problem is now in the development branch of the CoreLib project. Tests don't complete complete as the following error is thrown:
Uncaught Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'CoreLib' imported from /path/to/CoreLib/node_modules/CoreTestLib/lib/index.js
That tells me that CoreLib is not being picked up by TestCoreLib, even though TestCoreLib is in the node_modules directory of the CoreLib project. The first statement in TestCoreLib is an import from CoreLib, so I assume the error is being thrown as that import is not being resolved even though it should... right?
I always want the development version of CoreLib to be used by TestCoreLib, so I am concerned about adding CoreLib as a devDependency (instead of a peerDependency) of TestCoreLib as I worry that doing such will lock CoreLib into version conflict with its own prior release, but I am honestly confused about what would happen in that context.
The lazy boy moon shot of linking TestCoreLib to CoreLib does not solve the problem either, so I am obviously missing something fundamental that I would really appreciate your help with.
Do you know of any projects that successfully split their packages off into peerDependencies in such a way that you could refer me to?
Is there an elephant in the room sitting top of me and if so could you tell it to get off so that I can resolve this maddening issue and move on? LMAO
Be safe, well, calm, clear, happy fellow humans. Thanks for considerations.
The elephant in the room was... the lazy boy moonshot and my misuse of it. My automatic typing fingers told me five minutes ago by adding the scoped package name to it
$ npm link #emmington/CoreLib
npm link by itself is insufficient for a symlinking a scoped package folder.
Symlinking a package folder
Scoped Packaged
It appears to me that the dependency linkage on the npm site is only applicable to the current/latest version.
Is there some tidbit of information that I'm not aware of on how to determine what dependency version a package has other than by downloading it and inspecting the package.json file?
I feel like I'm wasting HOURS doing something I would expect to be much easier to do.
"It appears to me that the dependency linkage on the npm site is only applicable to the current/latest version."
Yes that's correct, www.npmjs.com will only show the dependencies for the latest version of a package.
Here are a couple of ways to discover what you want both programmatically and non-programmatically.
Programmatically:
Utilizing the npm view command with the following syntax;
npm view <pkg_name> versions --json
obtains a list of all versions available for a given package in the npm registry.
Note: The <pkg_name> part above should be substituted with the real package name.
For instance; running the following command for let's say the eslint package:
npm view eslint versions --json
prints the following to the console:
[
"0.0.4",
"0.0.5",
"0.0.6",
"0.0.7",
"0.1.0-dev",
"0.1.0",
"0.1.1",
"0.1.2",
...
]
Now we know what versions are available, let's say we want to list the dependencies for eslint version 0.1.2 we can run the following command:
npm show eslint#0.1.2 dependencies --json
This will print:
{
"optimist": "*",
"estraverse": "~1.3.0",
"esprima": "*",
"escope": "1.0.0"
}
Similarly, we can discover the devDependencies for eslint version 0.1.2 by running the following command instead:
npm show eslint#0.1.2 devDependencies --json
This will yield something like this:
{
"vows": "~0.7.0",
"sinon": "*",
"commonjs-everywhere": "~0.9.0",
"mocha": "~1.13.0",
"chai": "~1.8.1",
"grunt": "~0.4.1",
...
}
If you know that a package has a particular dependency in advance.
For instance; retrospectively after running the aforementioned command we now know that eslint version 0.1.2 has escope listed as a dependency.
So, if we wanted to know the version of escope that eslint version 0.1.2 needs, we can run the following command:
npm show eslint#0.1.2 dependencies.escope
^
Note: The package name follows the dot (.), i.e. .escope
This prints the following:
1.0.0
The non-programmatic way
I can't think of a reason why you would want to perform the following non-programmatic way instead of the aforementioned programmatic way when you have a CLI tool available to you. However, if you prefer manual tasks then here goes...
Note: YMMV using the following manual steps as it depends on how the package has been managed/maintained.
Typically, the source code of an npm package will be hosted on GitHub, so you can perform the following manual steps. This will avoid you having to download the package to inspect the package.json file.
For this we'll demonstrate for the eslint package:
Visit npmjs.com and type the name of the package in the "Search Packages" input field. We'll type eslint and hit the return key.
Next click eslint from the list of packages, which will take you to this page.
Click on the github link which typically appears on the right-hand side of the webpage and looks like this:
That will take you to the eslint repo, i.e. this one
On the Github page click the "Branch" button - which appears above the list of source code files, and looks like this:
In the pop-up panel that subsequently appears click the "Tags" button, then locate and click the version tag from the list that you want to discover it's dependencies. (Note: These tag names will typically correspond to the version released/published to npm)
This will then load the source code files in the browser for that particular release/version.
Locate the package.json file from the list of files and click it. This will load the contents of package.json in the browser, upon which you can read it and ascertain its dependencies.
Visualizing the dependency tree
I sometimes utilize this online tool https://npm.anvaka.com which can help you to visualize the complete dependency tree/graph for a given package - however it's for the latest version of a package only.
Here is the complete dependency tree/graph (many levels deep) for the latest version of eslint.
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
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.