Where can I learn more about what is workspace: prefix in version number?
For example, in Babel:
"dependencies": {
"#babel/helper-plugin-utils": "workspace:^7.13.0",
source
This is a feature of yarn 2.x. You can read more about this in the yarn documentation at https://yarnpkg.com/features/workspaces#workspace-ranges-workspace As a snippet:
For those use cases, Yarn now supports a new resolution protocol starting from the v2: workspace:. When this protocol is used Yarn will refuse to resolve to anything else than a local workspace. This range protocol has two flavors:
If a semver range, it will select the workspace matching the specified version.
If a project-relative path, it will select the workspace that match this path (experimental).
you could check about this dependency via using this command
yarn why <dependency-name>
Related
I am trying to add my modified version of vega as a local package as a dependency via:
yarn add vega#file:../vega/packages/vega
however, when I then do yarn, it tells me my package is invalid:
invalid: vega#5.22.1 /Users/alex/Documents/Work/Research/vega_profiler/VegaProf.nosync/editor/node_modules/vega
I think this is because it tries to match the version with the one in my package.json, which does not contain version information for the local package. However, I don't know how to address this.
I signed up for the Github private npm registry beta and followed their instruction: https://github.com/features/package-registry
Works great with npm but I'd prefer using yarn. And while npm has no issues finding the registered package, yarn can't find it at all.
yarn add #omniphx/adminite-adminite-ui-components outputs:
yarn add v1.19.0
info No lockfile found.
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍 Resolving packages...
error Couldn't find package "#omniphx/adminite-ui-components" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
After reading up on private repos with yarn, I thought the trick was due to yarn having a slightly different rc format. Unfortunately, that didn't work either and yarn is still unable to find the private registry.
.npmrc
registry=https://registry.npmjs.org
#omniphx:registry=https://npm.pkg.github.com/omniphx
.yarnrc
registry "https://registry.npmjs.org"
"#omniphx:registry" "https://npm.pkg.github.com/omniphx"
Also confirmed that my github token is set too with yarn config list:
yarn config v1.19.0
info yarn config
{
'version-tag-prefix': 'v',
'version-git-tag': true,
'version-commit-hooks': true,
'version-git-sign': false,
'version-git-message': 'v%s',
'init-version': '1.0.0',
'init-license': 'MIT',
'save-prefix': '^',
'bin-links': true,
'ignore-scripts': false,
'ignore-optional': false,
registry: 'https://registry.npmjs.org',
'strict-ssl': true,
'user-agent': 'yarn/1.19.0 npm/? node/v12.11.1 darwin x64',
email: 'mattjmitchener#gmail.com',
lastUpdateCheck: 1570679687836,
username: 'omniphx',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx'
}
info npm config
{
'//npm.pkg.github.com/:_authToken': 'fake12345',
registry: 'https://registry.npmjs.org',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx',
python: '/usr/bin/python'
}
Any idea?
Resolved
Changed "#myorg:registry" "https://npm.pkg.github.com/myorg"
To "#myorg:registry" "https://npm.pkg.github.com"
I've just run into a similar situation. It seemed that yarn was only looking in the main Yarn package registry for my organization's private package. I had copied the examples from GitHub's Packages documentation for constructing your .npmrc file directly to the .yarnrc file in the project that will be consuming the app, not knowing that the formats were different (I've never had to deal with .yarnrc files before).
However, after updating the .yarnrc file with the correct format that you've mentioned above (which I also found in googling around), yarn successfully found the private package and installed it correctly.
As a heads up, my yarn version: 1.17.3
Steps I Took
Start new terminal session
cd to the project
nvm use (if you have a specific node version to use)
Add the correctly-formatted .yarnrc file to the project. See below for what it looks like.
Manually add the package and version range to the package.json for my private package
Run npm login --registry=https://npm.pkg.github.com --scope=#MyOrg
See the note below on scope / org gotcha's
Run yarn
That worked for me.
.yarnrc
"#myorg:registry" "https://npm.pkg.github.com"
Note: See below for a note on the org / scope name gotcha's
Other Notes
I know that it appears that you don't have any issues with this, given your GH username / scope above, but for anyone else that comes here, the documentation on GH is a little sparse with regards to mapping your username / org name to a scope in the package name. Just remember these little gotcha's here:
The name of your package must always be scoped to your org (or username)
E.g., name: #johndturn/my-package
If your organization has capital letters in it, like MyOrg, just replace them in the name of the package in your package.json and your .yarnrc with lowercase
E.g., name: #myorg/my-package
Note: When authenticating with npm login, I still have kept the uppercase letters in the --scope= argument.
The name of your package doesn't have to be the same name of the repo.
E.g., for a repo called MyOrg/random-prefix.js-lib, you can have name: #myorg/js-lib in your package.json file for the project itself. Then, installing it in other projects will look something like #myorg/js-lib: 1.0.0.
The problem I had is slightly different.
After tried what John suggested I still can't add private registry packages with yarn (but perfectly fine with npm)
Then I realise two things:
For GitHub packages, npm is fine with either
registry=https://npm.pkg.github.com/my-org
or
#my-org:registry=https://npm.pkg.github.com
but yarn only allow the latter syntax.
Docs from Github website only show the first syntax which could cause problems for yarn users.
Another thing is that if you npm login to the private registry but use a .yarnrc file in your project, yarn can't really mix your npm credentials with it. Although it seems behave differently on different environment.
But it would seems to be a best practice to stick with either yarn login + .yarnrc, or npm login + .npmrc (you can still use yarn to manage your packages in both cases)
In Yarn v2+ the setup has changed quite a bit. ".yarnrc" is ignored and only ".yarnrc.yml" is used.
To setup a private registry with a scope and token from env, add something along these lines to the ".yarnrc.yml" file (fontawesome example):
npmScopes:
fortawesome:
npmRegistryServer: "https://npm.fontawesome.com"
npmAuthToken: ${FONTAWESOME_TOKEN}
Documentation: https://yarnpkg.com/configuration/yarnrc#npmScopes
I'm not an expert with npm/yarn so I might be misunderstanding what is happening here, but I don't think package proxying from the npm registry works with yarn yet. Could that be related? When package proxying was released for npm I remember reading comments on Twitter from people that tried it with yarn and it didn't work.
Found the Twitter thread here:
https://twitter.com/github/status/1171832034580451328
It doesn't work with Yarn. As soon as I change the registry url -> Couldn't find package.
I'm creating Conda create environment from yml I generated on Windows' Miniconda install. I need to create same environment on OS X. Following the advise found here on SO I used the --no-builds option.
Also, the names of some packages under section ResolvePackageNotFound are clearly (many if not all) specific to Windows:
- m2w64-gmp=6.1.0
- m2w64-gcc-libs-core=5.3.0
- m2w64-gcc-libs=5.3.0
- vc=14.1
- vs2015_runtime=15.5.2
- msys2-conda-epoch=20160418
- menuinst=1.4.14
- icc_rt=2019.0.0
- m2w64-libwinpthread-git=5.0.0.4634.697f757
- pywinpty=0.5.5
- wincertstore=0.2
- m2w64-gcc-libgfortran=5.3.0
- win_inet_pton=1.1.0
- winpty=0.4.3
I removed all of these from the yml file. Even then it's stalled at the following screen:
(base) MacBook-Air:Anaconda.d xtian$ conda env create -f 32b-qb-2019-10-05.yml
Collecting package metadata (repodata.json): done
Solving environment: \
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abor|
Examining openssl: 10%|█████████▍ | 29/279 [00:00<00:00, 3729.87it- ]
Comparing specs that have this dependency: 16%|██████████▉ | 16/101 [05:53<31:19, 22.11s/it]
Finding shortest conflict path for openssl[version='>=1.0.2p,<1.0.3a']: 38%|███████████████▊ | 6/16 [02:39<06:23, 38.32s/it]
This process is progressing at an astonishingly slow pace, and hasn't got past openssl ... 29/279. Should I wait and trust Conda can figure this all out?
Or,
Do I need another strategy--
I'm wondering if I can't remove the offending packages, each in turn, and create a series of yml files to install in order using, $ conda env update --prefix ./env --file environment.yml --prune, because whatever finally works here I know I'm going to need to use it on another machine so I can share the project env with a colleague.
Any other suggestions?
Short answer: Try deleting the packages that your system is getting stuck on from the .yml file. i.e., remove "openssl" from .yml file.
I have been running into the same issue trying to install a .yml file created in a Windows system to a Mac system. I basically followed the same procedure you did:
-Created yml file using the --no-builds option.
-Attempted to create environment on Mac system and had several windows specific packages left under ResolvePackageNotFound section (listed below)
m2w64-libwinpthread-git=5.0.0.4634.697f757
pyreadline=2.1
pywinpty=0.5.5
m2w64-gcc-libgfortran=5.3.0
vc=14
m2w64-gcc-libs-core=5.3.0
m2w64-gmp=6.1.0
wincertstore=0.2
icc_rt=2019.0.0
m2w64-gcc-libs=5.3.0
vs2015_runtime=14.15.26706
winpty=0.4.3
msys2-conda-epoch=20160418
-Deleted those from the yml file
-Attempted to create environment from updated yml file and received the following conflicts:
- Found conflicts! Looking for incompatible packages.
My system also got stuck trying to solve the "openssl" conflict along with a "_tflow_select". I ended up deleting those and was able to create my environment and run the code without too much trouble.
I am trying to install the MongoDB swift driver using the swift package driver. I followed their instructions and installed the mongo-c-driver using home-brew. I then created a new directory and within a new project using:
swift package init --type executable
I then added the dependencies to the Package.swift file.
When trying to run any command that summonsswift package resole in the directory, i get the following error:
error: the package PackageReference(identity: "mongo-swift-driver", name: nil, path: "https://github.com/mongodb/mongo-swift-driver.git", isLocal: false) # 0.0.2 contains revisioned dependencies:
PackageReference(identity: "swift-bson", name: nil, path: "https://github.com/mongodb/swift-bson", isLocal: false) # master
PackageReference(identity: "swift-mongoc", name: nil, path: "https://github.com/mongodb/swift-mongoc", isLocal: false) # master
I made sure that everything is up to date and that the first line of the Package.swift is // swift-tools-version:4.0
I would like to know what these revisioned dependencies are, as i have not found anything useful. And how this error can be resolved.
The Swift Evolution proposal that introduced the ability to specify branches instead of revisions in SPM packages (SE-0150 says this:
While this feature [specifying branches] is useful during development, a package's dependencies should be updated to point at versions instead of branches before that package is tagged for release. This is because a released package should provide a stable specification of its dependencies, and not break when a branch changes over time. To enforce this, it is an error if a package referenced by a version-based dependency specifies a branch in any of its dependencies.
It looks like the version 0.0.2 of the parent package that you're using did not follow the rule to switch to specific versions for its dependencies and SPM doesn't allow this.
If possible, you should try to use a newer version of the parent package that fixes this issue. If a newer version doesn't exist, you may have to override the dependency and fix it yourself (I believe you can use swift package edit to do that — or fork the dependency and point to your own repo, of course.)
I'm getting this error:
Unknown plugin "transform-class-properties" specified in "base" at 0, attempted to resolve relative to "/home/me/Projects/myproj/src"
The message is pretty clear, so I know why it's happening, but I want to change where Babel looks for the plugins/presets/packages.
I'm using Babel with rollup via rollup-plugin-babel.
The options I'm giving it are:
{ plugins: [ 'transform-class-properties', 'transform-object-rest-spread' ],
babelrc: false }
However, I can't find an option to change where Babel looks for the plugins. Is there no way to do this without rewriting my plugins list to use absolute paths?
I also can't find a public API method for extracting the dependencies from .babelrc, so it's pretty hard to manually rewrite the file to use full paths. N.B. Babel configs might also be stored in package.json, and there's been some talk about adding support for .babelrc.js too -- I really don't want to maintain my own project that searches for all the different places a babel config might be hiding, parse the file(s), and scan it for all the plugins, with and without the arbitrary babel-plugin- prefixes.
You can use NODE_PATH to do the same.
$ npx babel test.js
Unknown plugin "external-helpers" specified in "/Users/tarun.lalwani/Desktop/babeltest/.babelrc" at 0, attempted to resolve relative to "/Users/tarun.lalwani/Desktop/babeltest"
After specifying the path for modules in a different location
$ NODE_PATH=/Users/tarun.lalwani/Desktop/babeltest2/node_modules npx babel test.js
function test() {
this.abc = function (url) {
return console.log(url);
};
}
NODE_PATH environment variable allows you to specify additional locations where the modules can be searched for