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
Related
I'm newbie to go and I've created a file and init a mod inside of it by typing:
go mod init github.com/AnmarDc/e-commerce
After that, I made a folder called controllers which will contain all the controllers of my operations on my site and then tried to import it into my routes folder, but that didn't work.
I kept getting the following error:
Build constraints exclude all the Go files in 'C:/Users/engan/Go/src/Projects/eCommerce/controllers'
I thought it was about GoPath, or GoRoot, but I found it out it's because GoLand itself, but I have no idea how to fix it, as I can see everything seems reasonable to me.
GoEnv attached.
Oh, it looks like there's some issue in building constraints, I just imported the following code in my routers:
//go:build (linux && 386) || (darwin && !cgo)
and it worked perfectly.
Reference:
Constraints
Suppose you're developing some library, myproj, using CMake for build configuration; supporting the cmake --install (using install() commands); and supporting use of myproj with CMake config mode, i.e. by making relevant .cmake files accessible to dependent projects.
Now, ,given an install root directory - where should I install my project's configuration .cmake files? Is there an idiomatic standard(ish) location?
Sorush Khajepor's R&D blog suggests ${LIB_INSTALL_DIR}/cmake/myproj - and it's the newest.
Foonathan's blog suggests placing the config .cmake files in ${LIB_INSTALL_DIR}/. So does Falkor's blog.
The documentation page for the CMakePackageConfigHelpers module suggests: ${LIB_INSTALL_DIR}/myproj/cmake.
What's the most popular/idiomatic choice? And what are its pros and cons relative to the other ones?
I advocate for setting a cache variable to override this and defaulting it to <LIBDIR>/cmake/ProjName (as you suggest in your answer):
cmake_minimum_required(VERSION 3.21) # for saner CACHE variables
project(ProjName VERSION 0.1.0)
# ...
include(GNUInstallDirs)
include(CMakePackageConfigHelpers)
set(ProjName_INSTALL_CMAKEDIR "${CMAKE_INSTALL_LIBDIR}/cmake/ProjName"
CACHE STRING "Path to ProjName CMake files")
install(EXPORT ProjName_Targets
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
NAMESPACE ProjName::
FILE ProjNameConfig.cmake
COMPONENT ProjName_Development)
write_basic_package_version_file(
ProjNameConfigVersion.cmake
COMPATIBILITY SameMajorVersion)
install(FILES
"${CMAKE_CURRENT_BINARY_DIR}/ProjNameConfigVersion.cmake"
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
COMPONENT ProjName_Development)
I wrote a blog post with an expanded version of this a while back: https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html
In general, setting an install() destination to anything other than "${SOME_CACHE_VARIABLE}" is bound to cause headaches for some package maintainer. Where GNUInstallDirs doesn't provide a valid configuration point, you must create your own.
I'll argue in favor of ${LIB_INSTALL_DIR}/cmake/myproj.
If you're installing to some library-specific install location, e.g. /opt/myproj - then it doesn't really matter all that much anyway. But think about what happens when you install to, say, /usr/local.
If you place the scripts in ${LIB_INSTALL_DIR}, that library now becomes full of foo-config.cmake and foo-version-config.cmake, instead of just library files (and some subdirs). Less fun for browsing and searching.
If you place the scripts in ${LIB_INSTALL_DIR}/myproj/cmake, then - the same thing happens, but with per-project subdirs instead of sets of files. Better, perhaps, but instead - why don't we just replace the path elements of myproj and cmake, and that way we would get a cmake/ directory with many subdirs, instead. That's cleaner and more convenient IMHO.
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.
Following the release of Go 1.11, I have been trying to move my repositories to Go modules, by adding a go.mod file at their root.
One of my root libraries my.host/root is in its version 17.0.1, so I wrote in its go.mod file:
module my.host/root/v17
I tagged that version v17.0.1 as documented in the Go modules manual.
When I try to make a new Go project that uses my root library, like:
package main
import root "my.host/root/v17"
func main() {
root.DoSomething()
}
And try to compile it, I get the following error:
go: my.host/root#v0.0.0-20180828034419-6bc78016491a: go.mod has post-v0 module path "my.host/root/v17" at revision 6bc78016491a
I am at loss figuring out why this happens. I explicitly added v17.0.1 in the go.mod file, yet every attempt at go build replaces the entry with a v0.0.0-20180828034419-6bc78016491a version which then fails because at that commit, the go.mod file module entry of my root library indeed ends with a v17, as it should.
For the record, this commit is the same as the tagged v17.0.1 version.
What am I doing wrong here? How can I debug this situation?
I had make two mistakes:
My initial v17.0.0 tag would point to a commit where go.mod did not contain the v17 import path suffix. As a result, it seems Go tooling considers the whole v17 major version as a v0/v1 instead, even if later v17 tags point to a commit with a correct go.mod directive, hence the commit ID "translation".
In my dependent projects, in the go.mod file, I mistakenly specified
require my.host/root v17.0.1 instead of
require my.host/root/v17 v17.0.1.
After fixing both those issues, everything seems back to normal and it works perfectly. I wish the documentation had been clearer about this but I guess this is a good opportunity to make a contribution!
The error I got was: github.com/emicklei/go-restful#v0.0.0-20180531035034-3658237ded10: go.mod has post-v0 module path "github.com/emicklei/go-restful/v2" at revision 3658237ded10
Appending github.com/emicklei/go-restful with v2 like so: github.com/emicklei/go-restful/v2 in my go.mod file fixed it for me.
I'd like to try out the exp/regexp package. Currently Go tip's ./all.bash command compiles including only exp/regexp/syntax. I've been looking around the makefiles and I see it builds a Make.deps but couldn't figure out how it selects the packages that are included. What should I change to build Go with exp/regexp?
Duh, it was right in front of my eyes! Add the package dir to src/pkg/Makefile:
DIRS=\
archive/tar\
archive/zip\
asn1\
...
exp/regexp\
...