I'm using yarn v1.22 and yarn workspace for building my application as a monorepo. Here is the package.json for our component library package. I want to use publishConfig to override the main field when I do npm publish or yarn publish. But when I tried to run those commands, the main field is no changed. Can anyone share some suggestions? Thanks.
{
"name": "components",
"private": false,
"version": "0.1.2",
"main": "src/index.ts",
"files": [
"dist"
],
"publishConfig": {
"main": "dist/index.js"
}
}
Related
My top package.json:
{
"name": "foo",
"version": "0.0.0",
"private": true,
"workspaces": [
"apps/*",
"packages/*"
],
"devDependencies": {
"#foo/eslint-config": "*"
},
"engines": {
"npm": ">=7.0.0",
"node": ">=14.0.0"
},
"dependencies": {},
"packageManager": "npm#8.18.0"
}
and I have a package in packages/#foo/eslint-config.
However, when I do npm install, I get an error saying that #foo/eslint-config is not in the registry.
I am assuming that I have either wrong directory structure.
Figured it out.
The package should have gone directly to packages/eslint-config directory.
The package name still needs to have the scope, i.e. #foo/eslint-config.
It appears that workspaces do not use the same convention of nesting scoped packages under a sub-directory as node_modules do.
It also appears that the folder name has no significance, as long as it is directly in the directory defined in workspaces configuration and has the correct package name.
Alternatively, you can also just update your workspaces configuration to read from packages/#foo/*.
Is there a way to setup a local folder to be used as package.json repository. The goal is to be able to use the cloud repository (https://www.npmjs.com/package) but the modules which are not found there to be searched and installed from a local folder.
Example package.json:
{
"name": "myproject",
"version": "0.0.0",
"dependencies": {
"standard-npm-module": "1.0.0", // installed from https://www.npmjs.com/package/standard-npm-module
"local-module": "1.0.0", // installed from local folder because it wont be found in https://www.npmjs.com/package/local-module
}
}
PS Yarn or npm any solution will be OK.
you can use local paths. for instance, see the package.json snippet below.
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
you can also leverage npm, for instance:
npm install --save /path/to/module
I have angular in my dependencies at 1.5.11:
{
"dependencies": {
"angular": "1.5.11",
"angular-foundation": "0.7.0"
}
}
angular-foundation happens to depend on angular#>=1.3.0.
Why does Yarn install angular#1.6.9 as a nested dependency of angular-foundation instead of using the project's version? This causes angular to exist twice in the app and doesn't work properly:
node_modules
angular (1.5.11)
angular-foundation (0.7.0)
node_modules
angular (1.6.9)
This doesn't happen with npm#5.6.0 - npm uses 1.5.11 for both the app and the package.
You need to use Yarn resolutions for this
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/
So your package.json will become like this
{
"name": "depdencies",
"version": "1.0.0",
"main": "index.js",
"license": "MIT",
"dependencies": {
"angular": "1.5.11",
"angular-foundation": "0.7.0"
},
"resolutions": {
"**/angular": "1.5.11"
}
}
Which tells yarn that any child angular dependency will be set to 1.5.11. After updating this run below
$ rm yarn.lock
$ yarn
https://classic.yarnpkg.com/en/docs/cli/add/#toc-yarn-add-alias
yarn add <alias-package>#npm:<package>
yarn add react17#npm:react#17
I'm about to write a yeoman generator where the whole template is hosted on a git repository. So the package.json of my yeoman generator looks like
{
"name": "generator-foo",
"version": "0.1.0",
"description": "",
"files": [
"generators"
],
"keywords": [
"yeoman-generator"
],
"dependencies": {
"foo-template": "git://somewhere-in-the-world/foo-template.git#0.1.0",
"chalk": "^1.1.3",
"yeoman-generator": "^1.1.1",
"yosay": "^2.0.0"
}
}
Is there any way to prevent npm install from installing the foo-template package, i.e. running any postinstall script just for this package? Instead, it should be just downloaded to node_modules.
As describe here, postinstall scripts can be disabled globally for npm using --ignore-scripts flag.
As a complete solution, I would move your explicit dependency to foo-template to your local postinstall section with ignore scripts enabled:
{
"name": "generator-foo",
...
"postinstall": "npm install --ignore-scripts git://somewhere-in-the-world/foo-template.git#0.1.0",
"peerDependencies": {
"foo-template": "git://somewhere-in-the-world/foo-template.git#0.1.0"
}
}
Note that to make sure the dependency is explicitly described, we should mark it as a peerDependency (e.g. prevents package removal on prune).
I'm trying to use the npm package grunt-package-modules to gather my npm_module dependencies for a bundled deployment but ran into the error when running the command grunt packageModules:
Fatal error: Refusing to install test as a dependency of itself
This error typically occurs when the name of the project also appears in the list of dependencies in package.json as was the case here, but that does not occur in the original file or the one that is copied into the dist folder.
I was able to get this error with the simplest project setup I could create from the examples given in the grunt tutorial and the package wiki. Is there something I'm missing in setting up this plugin?
package.json
{
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"underscore": "^1.8.3"
},
"devDependencies": {
"grunt": "^1.0.1",
"grunt-package-modules": "^1.0.0"
}
}
Gruntfile.js
module.exports = function(grunt) {
grunt.initConfig({
packageModules: {
dist: {
src: 'package.json',
dest: 'dist'
},
}
});
grunt.loadNpmTasks('grunt-package-modules');
}
I'm on a PC and had the same thing happen on my home PC but had my co-worker run through this same setup on his mac and it worked successfully for him. Also tried updating node and npm since we had different versions with no luck.