Pardon my ignorance, if I am developing a library, should (some of) my peerDependencies be duplicated in my devDependencies? I'm thinking yes, right?
Example:
"peerDependencies": {
"#babel/runtime": "7.6.0", <- needed for consuming the transpiled library
"sugar-date": "2.0.6",
"yup": "0.27.0"
},
"devDependencies": {
"sugar-date": "2.0.6", <- this is actually a "dependency"
"yup": "0.27.0", <- this is actually a "dependency"
...
}
Because this is a library, if I put them as dependencies, then in the project that consumes them, they will install their own node_modules when the project might already contain these dependencies, resulting in duplicated code - so I put them in peerDependencies to avoid this. But now I can't develop (e.g. write tests), so I have to put them in devDependencies.
Is this correct? Am I misunderstanding something?
Related
is it possible for a monorepo to have two packages which depend on one another?
E.g.
package_Dashboard
import { table } from 'package_Style'
package_Style
import { style } from 'package_Dashboard'
During development, all seems to be working more or less fine thanks to aliases/references which replace
package_Dashboard with ../package_Dashboard'.
I have to not include the dependency in one of the package.json files, because otherwise lerna warns me about a circular dependency.
When I'd publish this on npm or similar, this wouldn't work anymore (due to the missing dependency in package.json).
So how does one best solve for a case like this?
Thanks!
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
In my package.json I have a package:
{
"somepackage": "^6.5.1"
}
This package has a dependency (from somepackage's package.json):
{
"someotherpackage": "^9.4.2"
}
I want to swap someotherpackage to one of its fork.
I know of yarn's Selective dependency resolution feature, but I guess that is only for different versions of the same package.
I could as well fork somepackage and change its dependencies manually, swapping someotherpackage to someotherpackage-fork, but if there is another way I would take that.
Thanks!
The mentioned selective dependency resolution feature is the way to go. Under the hood it seems to be resolving packages the same way dependencies does which allows us to do the following:
"resolutions": {
"**/someotherpackage": "npm:someotherpackage-fork#*"
}
You can also specify which version of your fork you want:
"resolutions": {
"**/someotherpackage": "npm:someotherpackage-fork#3.0.2"
}
I haven't confirmed if this works for Yarn version 2 yet.
Showcase: https://github.com/dimitarnestorov/yarn-resolutions-showcase
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
In order to convert some dynamic HTML to React's JSX, in my ASP.Net MVC based project I want to use htmltojsx, but can't figure out how to incorporate it in the project as it involves requireJS and probably some other JavaScript dependencies.
If someone can describe it in an easy/clear manner, would be of great help. Will salute you if some working example fiddle is also provided.
OK, posting answer to my own question after a long time. Here is a brief summary of what I found out during my research on this topic in past few weeks.
Actually it involved exploring various co-related topics before to getting onto the right point.
To understand how to incorporate packages (especially npm based) like htmltojsx into web apps, we need to understand first 'Modules'.
By 'Modules' we mean a composed set of highly decoupled, distinct pieces of functionality that we have also the ability to dynamically load, sort of something like 'Import' statements we have in C# and some other Server side Languages.
Most modules are either based on CommonJS or AMD formats. Here is a very nice Blog on these. Please do read it first for a through understanding.
Writing Modular JavaScript With AMD, CommonJS & ES Harmony
To make us enable to use these modules in any web application there are then Module bundlers like Webpack, Browserify etc.
In short, a Module bundler takes modules with dependencies and generates static assets (like .js/.css files etc.) representing those modules.
These static assets can then be used in any web page like we do with HTML script/link tags normally.
Also to mention here, for using Webpack/Browserify one must first understand node's npm package manager which has become heart and soul of all Javascript's module based applications. Basically npm is a package manager and makes it easy for JavaScript developers to share and reuse code. It has become the de-facto standard behind the creation of well managed module based applications.
For using this an understanding of package.json is primary and vital step.
A developer must have to define the dependencies in a file named as package.json that describes modules/packages that an application will depend upon.
There are mainly two kinds of dependencies. Normal dependencies, defined in "dependencies" option (which are packaged along with the output static asset(s)) and "devDependencies" (which take part in compilation of modules and/or their resources). A typical devDependency is Babel, which is used to compile ES6 aka ES2015, React etc. to ES5 syntax which all major Browsers can understand.
After defining these dependencies in package.json file, we can just use them using a simple require statement, example:
var webpack = require("webpack");
An example package.json file would look something like this:
{
"name": "my-sample-app",
"description": "My sample app",
"version": "1.0.0",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "John",
"dependencies": {
"classnames": "^2.1.3",
"datejs": "0.0.2"
},
"devDependencies": {
"babel": "^6.3.26",
"babel-core": "^6.4.0",
"babel-loader": "^6.2.0",
"babel-preset-es2015": "^6.3.13",
"css-loader": "^0.23.1",
"style-loader": "^0.13.0",
"webpack": "^1.12.11"
}
}
Once we understand package.json and some npm commands, using webpack we can compile modules into static assets and then use them in any web page.
Here are also some links that can help us understand all this better:
Getting Started With React ES6 & Webpack
Setting up React for ES6 with Webpack and Babel