As per
https://nodejs.org/dist/latest-v16.x/docs/api/all.html#all_packages_packagemanager
We can specify package manager from the list of supported package managers.
However, the VS code complains that the value is not correct.
I have also tried following values which also gives warnings
pnpm
pnpm#6
pnpm#6.0.0
pnpm#^6.32.4
#jonrsharpe, still the same warning without space
The packageManager field requires to match the following regex
(npm|pnpm|yarn)#\d+\.\d+\.\d+(-.+)?
And
"packageManager": "^pnpm#6.32.4"
seems to resolve the warning but, for example
"packageManager": "123!##pnpm#6.32.4"
also meet the regex, which implies that the former might not work as intended.
According to the PR on nodejs (deps: add corepack #39608)
How does Corepack work?
The sources are located inside nodejs/corepack. The gist is that Corepack installs "jumpers" next to the Node binary (just like what already happens for the npm and npx binaries) for the supported package managers (binaries are currently pnpm, pnpx, yarn, and yarnpkg, plus an extra one for corepack itself). They thus become exposed through the $PATH environment variable. Once called, these jumpers look into the local folder to find the top-most package.json, and read the packageManager field from them. Depending on the result:
If no packageManager field exists, the requested version is assumed to be the defaults ones in the Corepack configuration.
If a packageManager field exists, then it's used as the requested version.
And in Corepack configuration,
"pnpm": {
"default": "7.3.0",
...
}
The default version of pnpm is 7.3.0 as of now, which is used when packageManager field is omitted,
So it is best to set
"packageManager": "pnpm#6.32.4"
to ensure it working as intended.
Thanks to #jonrsharpe, the correct way to specify is
pnpm#6.32.4
The correct way to specify is:
"packageManager": "^yarn#1.22.19"
or
"packageManager": "^pnpm#6.32.4" ...
Related
I have a repo with many npm packages inside, using npm workspaces
The top-level package.json contains the line:
"workspaces": [
"*"
]
When I run npm i -ws or other npm commands, I receive the warning:
WARN: some-package-name in filter set, but no workspace folder present
I'm not quite sure what the message means - I think the 'filter set' is the -w option, but the workspace folder some-package-name definitely exists.
One note is that the some-package-name/package.json contains an org prefix, eg:
"name": "#mycompany/some-package-name",
So maybe that's the cause. I can't rename the folder from some-package-name to #mycompany/some-package-name though as I'm concerned a directory starting with # may break things.
What does the warning mean and how can I resolve it?
I ran into the same problem, using the name configured in the workspace's package instead of the folder name fixed the issue for me, even with an #.
npm install --workspace=#mycompany/some-package-name
I have a slightly different answer.
I'm creating a package.json programatically, using Fs.writeFileSync('./path/to/package.json').
I run npm install -w=workspace foo bar immediately after, but it seems that this fails sometimes; NPM somehow hasn't picked up on the file, as if I run the same command twice, the second one always works.
Adding a small delay using setTimeout() also works, though I feel a bit dirty having had to do this; I don't know if this is an issue with Node or my lack of knowledge around Node's process lifecycle.
Anyway, in this case – and in lieu of better solution – it works.
I solved this issue using a file: dependency as "recommended by npm" (read below).
Actually many articles say that npm recommends to use file: to reference a dependency between two workspace packages (and then often they use the asterisk anyway) but honestly I did not found that hint in npm docs, but it works! ... at least it worked for me, using the following
Explicitly list the workspaces
So instead of using an asterisk I have, for example
"workspaces": [
"packages/models",
"packages/database",
"webapp"
]
I also have a scoped package name
for instance
"name": "#project/models",
"private": "true"
I am using "file:" dependencies
Instead of
"dependencies": {
"#project/models": "*"
}
I use file:WORKSPACE_PATH
"dependencies": {
"#project/models": "file:packages/models"
}
For instance, say I have "foo: ^1.0.0" listed in my package.json and that project's released versions are [1.0.0, 1.1.0, 1.2.0, 2.0.0]. I want to find out what ^1.0.0 resolves to without installing or looking it up manually. Does a tool for this exist? I would expect it to be something like npm resolve foo#^1.0.0
Yes there is!
If you're using npm use view
npm view foo#^1.0.0
Otherwise you could use yarn with info
yarn info foo#^1.0.0
And in case you want even better statistics check out bundlephobia. It gives size estimations for the given version as well as the others and also an analysis of the exports.
I am using npm version 2.15.11 and node version 4.7.2 on ubuntu 14.04. I want to publish my packages. when i use the command:
npm publish
i am geting the error: You need a paid account to perform this action. For more info, visit: https://www.npmjs.com/private-modules
Below is the screenshot of error:
Please provide me the solution to overcome this issue. Thanks in advance.
Run
npm publish --access=public
the first time you publish a scoped package.
The default access setting is private, but for this you need a paid account. Hence the error message.
In addition to the command line option provided by bersling, you can merge the following into your package.json:
{
"publishConfig": {
"access": "public"
}
}
Reference in npm documentation. Useful when you want to template it into your package manifests and not think about it.
P.S. had one of those old OpenId accounts, forgot to update it before it was nuked, no longer have the ability to add this as a comment to bersling's reply, which is where I feel this really belongs.
In package.json, npm version 6+ you have this option:
"private": true/false,
Be sure is false, and also try to use this flag:
npm publish --access=public
you probably initialized your package with a scope so that it is private. Read
https://docs.npmjs.com/private-modules/intro
Just want to add that, if you tried all the other answers and still get this error, someone(maybe yourself) could have somehow changed the package to private previously, in which case, you need to set the package to public before you could publish again... Orz
If my package has these dependencies
{ "name": "my-package",
"dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }
And the foobar package has these dependencies
{ "name": "foobar",
"dependencies": { "baz":"^2.0.0" }
and the most recently released version of baz is 2.1.0, the first run of yarn will install baz#2.1.0 in foobar/node_modules.
How do I force yarn to use the baz#2.0.9 package for foobar?
My understanding is that this would be possible using npm shrinkwrap (a la this question).
The summary of my question probably is: Yarn creates repeatable, deterministic installations, but how do I customize that installation?
If you do in fact have a sub-dependency that is overly restrictive in what versions it will accept, you can override them using yarn.
UPDATED EDIT: Yarn now, as of 1.0, officially supports the "resolutions" block. So the way to override resolutions is to just add a block like this to package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
You'll get warnings for "incompatible" versions sometimes, but I find that some packages (like socket.io) are overly restrictive in what version they accept, and so I'll happily select the latest version when it doesn't actually break things.
Original but outdated answer below.
It sounds like the original question wasn't exactly correct, but the original question was in fact the one I wanted answered, and I found an answer, so here it is for posterity:
I'm using the socket.io library, and it has component-emitter as a dependency. But it has a pair of versions that it requires. This is what the yarn.lock file looked like before I changed anything:
component-emitter#1.1.2:
version "1.1.2"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"
component-emitter#1.2.0:
version "1.2.0"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"
So it was including two copies of the component emitter in my client code. I looked, and there didn't appear to be any breaking changes between 1.1.2 and 1.2.0 (or 1.2.1, which was current). I first tried just changing the yarn.lock file:
component-emitter#1.2.1, component-emitter#^1.2.1, component-emitter#1.1.2:
version "1.2.1"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"
This worked, but the file has warnings about it being autogenerated, meaning that every single update or new package I add will stomp on this change. A bit of searching found the yarn --flat option, which will force yarn to choose no more than one of each package in the entire project. That seems like overkill to me, since I'm sure there are actual cases of incompatibility between older and newer packages. I just wanted to eliminate a redundant package from my client code, to make the download smaller; I still want the development packages to all work correctly.
But in the docs to yarn --flat I found a reference to a "resolutions" block that can go in package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
So I tried putting "component-emitter" : "1.2.1" in a new "resolutions" block in my package.json, and it in fact flattened component-emitter to 1.2.1 for all places that required it, and now I have only one copy in my client code.
(And now the resolutions block is completely supported in yarn, so you don't even need to use --flat.)
This is now possible with yarn's selective version resolution feature.
In your project's package.json, use resolutions:
"resolutions": {
"foobar/**/baz": "2.0.9"
}
This overrides package foobar's (and any other packages under it) version of baz, forcing it to be version 2.0.9.
EDIT: This is now deprecated, please read this answer instead:
https://stackoverflow.com/a/46615878/2398593
#SomeCallMeTime's answer is great and we've been doing that for month at work.
Unfortunately, this is not possible anymore since the v0.24.x (see that comment).
There's an opened PR on Github with an RFC proposal to have a simple way of handling that use case without having to keep an eye on the generated lockfile.
In my nodeJS project suddenly it give error.I do not any upgrade or changes.
When I write NPM start in command line it give that error
ERROR in ./~/css-loader?sourceMap!./~/postcss-loader!./~/sass-loader?
sourceMap&outputStyle=expanded&includePaths[]=c:/TFS/rc1/app/scss&includePaths[]
=c:/TFS/rc1/~/compass-mixins/lib&sourceMap&sourceMapContents=true!./app/scss/_toolkit.scss
Module build failed:
undefined
^
Functions may not be defined within control directives or other mixins.
in c:\TFS\rc1\node_modules\compass-mixins\lib\compass\functions\_lists.scss (line 81, column 3)
# ./app/scss/_toolkit.scss 4:14-337
I reinstall compass-mixins package but it still give same error.Then I looked _lists.scss that file in 81 line there is a code .I deleted that bu it give same error.What should I do?
#if not(function-exists(compact)) {
#function compact($vars...) {
$list: ();
#each $var in $vars {
#if $var {
$list: append($list, $var, comma);
}
}
#return $list;
}
}
I also face the similar problem. And my project is using gulp-sass and compass-mixins. As heart.cooks.mind points out that, gulp-sass is depending on node-sass. And node-sass upgrade one of its dependence libsass to version libsass 3.3.3 Delorean since node-sass 3.5.1.
However, one of libsass 3.3.3 Delorean changes is related to this problem:
'Disallow functions to be defined in control directives or mixins (#mgreter, #1550)'
Obviously, _lists.scss in compass-mixins break this rule. Seems someone raise an issue to compass-mixins and they have idea on fixing it.
Before compass-mixins release the issue fixed version, my temporary workaround is to delete node_modules/node-sass manually and npm install node-sass#3.4.2
I had the same issue,please refer to node sass release 3.5.3 is breaking build and force lock gulp-sass to use the specific node sass library using shrinkwrap and avoid using the buggy version of node sass
I am using Gulp. Version 2.3.0 of gulp-sass breaks it. Go back to Version 2.2.0 and you are all fixed.
Edit:
The real culprit is the node module inside the "gulp-sass" node module known as "node-sass". You can see inside "gulp-sass"'s package.json file that it simply pulling version greater than ^3.5.3.
Even if you go back and reinstall "gulp-sass" to 2.2.0, as I suggested earlier, the package.json file in there will still pull "node-sass" greater than ^3.5.3.
If I use the older version of "node-sass" 3.4.2 that error goes away. I don't know how to fix that in an automated way. In a pinch I was able to fix the problem by copying that folder (that is using 3.4.2) from a different project that works. Now it compiles.
Can someone smarter than me figure out a better way to accomplish this result?
What I (temporarily) did, was to install globally the node-sass v3.4.2, and then replace the gulp-sass version of node-sass (it is located within gulp-sass/node_modules) with this older one.
sudo npm install -g node-sass#3.4.2;
sudo cp -r /usr/lib/node_modules/node-sass/ /usr/lib/node_modules/gulp-sass/node_modules/;
Btw, there is a PR waiting to be merged for this. But if you want to use this today then there's a fork of the merge too.
If you want to use latter then just put compass-mixins: tjenkinson/compass-mixins in your package.json and all will be good.
Update:- There's also an npm package for the latter mentioned in the PR now
Update 2:- This should no longer be a problem with v0.12.8 now