According to Ethereum Developers' Guide:
You can build all code using the go tool, placing the resulting binary
in $GOPATH/bin.
go install -v ./...
What does ./... do in the context of:
go install -v ./...
That will install any "main" packages found in the current or subdirectories,
"subdirectories": that is what the ./... syntax means.
It forces go install to consider not just the current folder/package ('.'), but also the ones in the sub-folders: "..."
See "What is a sensible way to layout a Go project": you can have multiple packages "main", in a library driven development:
Moving the main.go file out of your root allows you to build your application from the perspective of a library. Your application binary is simply a client of your application’s library.
Sometimes you might want users to interact in multiple ways so you create multiple binaries.
For example, if you had an “adder” package that that let users add numbers together, you may want to release a command line version as well as a web version.
You can easily do this by organizing your project like this:
adder/
adder.go
cmd/
adder/
main.go
adder-server/
main.go
Users can install your “adder” application binaries with “go get” using an ellipsis:
$ go get github.com/benbjohnson/adder/...
And voila, your user has “adder” and “adder-server” installed!
Similarly, a go install -v ./... would install “adder” and “adder-server” as well.
Note: the -v print the names of packages as they are compiled.
Related
I have a React Native app built using TypeScript, and I would like to also develop a number of CLI tools to help developers and 'back office' folks, also using TypeScript. I would like these to live in the same monorepo.
Based on advice from colleagues and my own research, I have tried doing this by creating a subfolder in the repo, and creating a second package.json (and all the other config files), and npm install-ing as if it were a completely separate project. It didn't take long for this to become a total mess, primarily with duplicate imports where one thing mysteriously seems to import modules from the other targets' node_modules, but also just remembering to re-npm install all the different subprojects before each commit, etc. It gets even more confusing with the TS build folders lying around; they're another place for people to import the wrong thing from. The confusion caused by this approach has been a significant drain on productivity, and it feels like there has to be a better way. So that's the question:
What is the best practice for building multiple TS/Node targets (and by "targets", I don't mean ES6 vs ESNext, I mean in the C/C++ sense: multiple output "programs", so in this case I want it to both create the bundle necessary for my RN app, but then also generate a CLI executable.) that all share code with one another, from a single monorepo?
If it matters, I am also using Expo.
You're essentially describing a monorepo. pnpm has fantastic tooling out of the box for this.
Download the pnpm CLI and install it:
$ npm i -g pnpm # Download pnpm
$ mkdir monorepo # Create a new monorepo folder
$ cd monorepo
$ mkdir packages # This will be the folder where you add your
# apps, libraries, etc.
$ touch package.json # Create a package.json
$ echo "{}" > package.json
Create a pnpm-workspace.yaml file and add the following:
packages:
- 'packages/**'
Congratulations. You now have a monorepo where you can add multiple apps. Here's how it works:
Every folder under packages that has a package.json file is now a Node app that you can control using pnpm from the root of your workspace.
When you run pnpm i from the root, it will install all of the dependencies for all of your apps and libraries.
You can even install libraries that you create locally without needing to run npm link, or deal with adding file:../ to your package.json or any of that mess.
pnpm also supports running scripts across all of your repos at the same time.
I made an example project for you to look at. In this example, you'll notice I created a library named my-library and a dependent app named awesome-app. When I ran
$ pwd
~/stackoverflow/packages/awesome-app
$ pnpm i my-library
pnpm knew to pick up my workspace library automatically:
{
"name": "awesome-app",
"dependencies": {
"my-library": "workspace:0.1.0"
}
}
Note the workspace:0.1.0 that matches the version of the package I have in my repo.
I love pnpm. It isn't without its faults, but I've been very productive with it. There are also other alternatives, such as Lerna, and npm and yarn support their own workspace protocol. I just find pnpm to work the best and has the least amount of ceremony.
Enjoy.
I am developing small desktop application with web GUI (ReactJS) and python backend (Flask). I need to pack this application to deb-package for simple distribution.
For now scheme is pretty simple: I have standard setup.py file where python dependencies are described and debian/rules which uses dh-python to parse that file and extract dependencies to debian/control (if I understand correctly):
#!/usr/bin/make -f
export DH_VERBOSE = 1
export PYBUILD_NAME=myapp
%:
dh $# --with python3 --buildsystem=pybuild
All this works fine but the problem is that I need to manage npm-dependencies as well (for GUI part). I can't add something like npm run build as a custom build step to my setup.py since pybuild is setting proxy-server to avoid downloading of any side packages (only deb-dependencies are allowed). There are no deb-packages for my npm-dependencies and I don't want to create them myself.
So the only way I found is to add npm-dependencies (files like bootstrap.min.js, etc.) or bundle.js to git-repository, which seems bad. Is there any other way I can solve the problem?
I have a pretty common (i guess) problem. Many of my projects utilize nodejs, some for business logic, others only for some building task.
I need to have different runtimes in different projects, one of my electron apps requires node 7.10.0, a typical build suite requires node 8.x.
Now i know - i can use sudo n 7.10.0 or sudo n latest to switch the runtime globally on my computer (For those, who dont know this - have a look at "n")
Anyway, IMO this is not so convenient (some times, i need to rebuild all the modules after switching versions, often i forget to switch and so on). Is there a way of telling node which interpreter to use? Can i use a .npmrc file in a project directory to force a specific nodejs version within that subdirectory?
I searched exactly for this (npmrc node version) but was not lucky enough to find something.
Okay, i found a similar quesion:
Automatically switch to correct version of Node based on project
it seems you can install "avn" and use a .node-version file to do exactly that.
sudo npm install -g avn avn-n
avn setup
then you can create a .node-version file in your project and enter the desired version
echo 7.10.0 > .node-version
Then avn will detect that and activate the correct version
Unfortunately i get an additional permissions error. So to make this work, you need to install/configure "n" to work without sudo/root.
If you're fine with using another tool you could use nvshim.
pip install nvshim # this is all you need to do
It does not slow your shell startup or switching directories, instead moving the lookup of which node version to when you call node, npm or npx by shimming those binaries. More details in the docs.
Source, I wrote the tool.
NVM (Node Version Manager) allow us to use different versions of node quite easily on a single machine. You can have a look at here how to configure and use it.
Volta can used to manage multiple nodejs, npm or yarn versions on different projects on same machine. It's cross-platform.
For example you can run volta pin node#14 in project directory and this will set node to v14 if it exists otherwise it will download and then set it.
More information here https://docs.volta.sh/guide/
I am coming over to Go from Node.js and I am used to adding all my modules and then people just have to go npm install when cloning my package.
What is the equivalent of this with Go? I have a few imports and don't want people to have to manually install it if they use my package.
I also not sure if I create a simple Go application with just a package main if that allows people to just go get. I have really picked up on the Go way of repo sharing like Node.js
What is the equivalent of this with Go? I have a few imports and don't want people to have to manually install it if they use my package.
You don't have to do anything. People will not have to manually install the packages you import. When someone does
go get github.com/FrickeFresh/awesome
all of the dependencies you import in your awesome package will be downloaded automatically as needed.
Go get skips testing files by default, but a user can download those too by including -t:
go get -t github.com/FrickeFresh/awesome
But that's not something you need to worry about.
If you want to delve into vendoring specific versions of dependencies, there are a number of articles/tools available. The official tool is dep:
https://github.com/golang/dep
Basically you should take a look at vendoring. There exist tools that help you with versioning. Personally, I use vendetta which is just a little tool that "go gets" the referenced packages as git submodules into the vendor folder. So if anyone checks out my repo they simply do git submodule update --init --recursive. The package version can be specified as a git commit id in the respective submodule.
There also exist tools where you maintain the deps in a file, check out here.
I need to use rapidjson as a third party library to replace libjson. I'm trying to figure out how to build it so I can use it's build files in my project (dependency list).
I downloaded rapidjson from github, and I'm trying to get a buildable project. I'm looking at the instructions at rapidjson website, and it's showing that I need to do the following, below (Installation).
We don't use git, so what would I need to do instead of the git submodule update --init step?
Why would I need a build dir in the include/rapidjson directory with nothing in it?
When I cd to build and type cmake, it seems to be missing parameters. What is the full cmake command? Thanks!
Installation
RapidJSON is a header-only C++ library. Just copy the include/rapidjson folder to system or project's include path.
RapidJSON uses following software as its dependencies:
•CMake as a general build tool
•(optional)Doxygen to build documentation
•(optional)googletest for unit and performance testing
To generate user documentation and run tests please proceed with the steps below:
1.Execute git submodule update --init to get the files of thirdparty submodules (google test).
2.Create directory called build in rapidjson source directory.
3.Change to build directory and run cmake .. command to configure your build. Windows users can do the same with cmake-gui application.
4.On Windows, build the solution found in the build directory. On Linux, run make from the build directory.
On successfull build you will find compiled test and example binaries in bin directory. The generated documentation will be available in doc/html directory of the build tree. To run tests after finished build please run make test or ctest from your build tree. You can get detailed output using ctest -V command.
It is possible to install library system-wide by running make install command from the build tree with administrative privileges. This will install all files according to system preferences. Once RapidJSON is installed, it is possible to use it from other CMake projects by adding find_package(RapidJSON) line to your CMakeLists.txt.
It is header-only library. So if you just want to integrate it into your project, just copy the /include folder to your project, and it should works.
All other instructions are for building unit tests, performance tests and documentation.