I am tring to unhoist #nestjs/* modules in my monorepo
In my root's .npmrc
I tried
hoist-pattern[]=!#nestjs/*
I am not sure this is right syntax for all my projects
possible options ?
I am not sure but maybe one of them ?
hoist-pattern[]=!#nestjs/*
hoist-pattern[]=*
hoist-pattern[]=!#nestjs*
hoist-pattern[]=!#nestjs*
hoist-pattern[]=!*#nestjs*
hoist-pattern[]=!**/*/*#nestjs*
Related
I'm on version 1.22.X
I have a workspace like this:
/application
/common-package
/project-a
/project-b
Project A and B has similar dependencies but on different versions, this causes a bunch of issues so I want to add Project B to the workspace but I don't want Project B to hoist any dependency in the Application workspace.
I just want Project B to be able to import things from Common-Package.
I have tried:
/application/package.json:
"nohoist": [
"**/application/project-b",
"**/application/project-b/**",
]
But this isn't working and still sends some dependencies to application/node_modules.
I've also tried:
/application/project-b/package.json:
"nohoist": ["**"]
But again some packages still get hoisted. Then VS Code complains it cannot find them
I have a project with yarn (v1) workspaces.
project/
packages/
pkgA/
subPkgA1/
pkgB/
package.json has this:
"workspaces": {
"packages": [
"packages/pkgA",
"packages/pkgA/subPkgA1",
"packages/pkgB"]}
note that there's a nested workspace in there.
Top-level has jest#27.4.7 in its package.json.
pkgA has jest#24.9.0 because one of its dependencies requires that version; its package.json has no entry for jest.
pkgA/subPkgA1 has jest#27.4.7 in its package.json, BUT it actually gets 24.9.0 installed in its node_modules/.bin/jest, presumably because its parent workspace has that.
My main question is how to get jest#27.4.7 in the nested package subPkgA1? I tried adding an entry in pkgA's package.json, but that didn't help.
BTW, I know nested workspaces aren't fully supported until Yarn v2, but I can't upgrade right now, and I can't easily move my subpackage out of its parent, so any hacky solution would be better than nothing.
I wrote a program and want to encapsulate some logic.
So I did new module and pull it in my git. Link for git looks like
gitlab.xxx.ru/group/subgroup/proj
but when I tried to get it with go get, I got error
fatal: «https://xxx.ru:#gitlab.xxx.ru/group/subgroup.git/» unreachable: URL using bad/illegal format or missing URL
Go tried to load subgroup instead project.
I made folder gitlab.xxx.ru/group/subgroup/ in $GOPATH/src/ and clone my project.
And now it wrote
could not import gitlab.xxx.ru/group/subgroup/proj (no required module provides package "gitlab.xxx.ru/group/subgroup/proj")
So, if I understand correctly, in Golang 1.16 I can't just put my project in the correct directory and I can't use local packages.
How to fix loading from my GitLab and load it with ssh?
Thank you.
UDP go.mod in my proj.
module gitlab.xxx.ru/group/subgroup/proj
go 1.16
require (
golang.org/x/sys v0.0.0-20210608053332-aa57babbf139
golang.org/x/text v0.3.6
)
You may be hitting the intended behaviour from Gitlab which will prevent go from fetching the list of subgroups while trying to compute project dependencies. Since go get requests are unauthenticated, existing projects not under the root group are invisible and cannot be found.
To overcome this limitation, which Gitlab has yet to provide a solution, you can use one of the following two approaches:
Have the project located at the root and not in a subgroup (not always possible)
Leverage the .git extension as well as the replace directive in the project which imports your module (see below)
Go is able to fetch the project living under a subgroup if it knows the version control qualifier (.git). To indicate this, make sure you import the project using the following format gitlab.xxx.ru/group/subgroup/proj.git
While this alone works, it would force you to have all those .git in your imports. To overcome this, you also need a replace directive in your go.mod so you can use the original import path.
In the end, the project which imports your module should have a go.mod that look like this:
require(
gitlab.xxx.ru/group/subgroup/proj v1.7.0
)
replace(
gitlab.xxx.ru/group/subgroup/proj => gitlab.xxx.ru/group/subgroup/proj.git v1.7.0
)
If I run :
pnpm install eslint
Then my node_modules directory ends up containing:
node_modules
.bin/
.pnpm/
#eslint/eslintrc
eslint
eslint-scope
eslint-utils
eslint-visitor-keys
.modules.yaml
I can't seem to find anything particularly special about eslint or its dependencies that would cause that, but maybe I'm not looking at the right place.
The only thing that makes sense is that pnpm is hoisting these dependencies at the top solely based on the fact that they are prefixed by the name of the package I actually installed. That really doesn't seem right though.
What am I missing here?
In case someone else hits that head-scratcher:
The answer is simply that the default value of public-hoist-pattern contains *eslint*, so all eslint-related modules are special-cased.
see: https://pnpm.io/npmrc#public-hoist-pattern
In my projet MyProject (I'm using cocoapods), I want to use MyPod.
The classes of MyPod are copied to MyProject, but not the .pch. Hence, the project is not compiling.
So, I have two questions :
How can I add the .pch of MyPod to the imported classes of MyPod?
Is there a way to "include" the .pch of MyPod in the .pch of MyProject (or, to "modify" the latter)
I am sure 1. is possible. I am learning cocoapods right now.
EDIT
As said in the documentation of cocoapods, the prefix_header_contents attribute of a .podspec is "not recommended as Pods should not pollute the prefix header of other libraries or of the user project."
So, is there any other way? Are we supposed to develop libraries without anything in the .pch?
You have to use the following property:
s.prefix_header_contents
For instance: s.prefix_header_contents = '#import "SomeClass.h"'.
It will add this line of code to the pch file associated to the Pod.