to sum up my circumstances:
I am running everything locally
I am using flask in the backend within a virtual environment
Goal: build a socket connection between Flask Backend and JS Frontend
PROBLEM: the problem is in the Frontend which is based on JS where I can't import the modules I got with npm
I am importing the modules as follows:
import { io } from "socket.io-client"
import { Hands } from "/#mediapipe/hands"
I also tried different import variants such as import * as io from "socket.io-client" and I also tried importing directly files as follows: import {io} from "socket.io-client/dist/socket.io", but all without success as these lead to "not found" errors.
I am sure that I installed them correctly with npm as I can see them in the folder structure, but the es6 imports are throwing an error as follows:
Failed to resolve module specifier "socket.io-client". Relative references must start with either "/", "./", or "../" - To solve this I tried adding slashes to different places like in the html tag where I include the script I tried transforming "type="module"" to "type="/module"" as recommended somewhere online, but without success. Also building direct references in the imports like "./node_modules/socket.io-client" do not work as it states that the file/folder is not found.
The problem must be the usage of the imports as everything works when I use Content Delivery Networks which also lets me assume that the version of the packages is not the problem as the version I get from the CDN is the same, but still the versions I use:
socket.io-client: 4.6.0
#mediapipe/hands: 0.4.1675469240
Flask: 2.2.3
Flask-SocketIO: 5.3.2
npm: 8.19.3
node: 16.19.1
My folder structure is as follows:
venv
main.py
templates
index.html
static
node_modules (includes socket.io-client and #mediapipe/hands)
js
main.js (the js file where the problem occurs)
package.json
I read a few times that the usage of "Webpack" is recommended, but I would like to skip that currently as I am not very familiar with that, so one question would also be: is it necessary to use it?
What can I possibly do wrong or how can I track my problem when it is about the import of es6 modules?
I would appreciate any help. Thanks in advance!
I could solve my problem for the socket.io-client package:
For the socket.io-client I imported a specific file directly although I do not really know why it worked as follows:
import { io } from './node_modules/socket.io-client/dist/socket.io.esm.min.js'
For the mediapipe package I still could not import the module in my js file directly and I am still relying on CDN. I tried the same thing in the same way by using:
import * as Hands from './node_modules/#mediapipe/hands/hands.js'
This, at least, does not result in an error, but the usage of "Hands" in this case is unclear to me as there is also no documentation for this use case in the mediapipe-js documentation. I could not directly import the {Hands} function as it resulted in an error saying "there is no function Hands in that path"
I'm using WebStorm 2017.1.3, although also tried with latest EAP, and i can't get import from statement to work. I just keep getting the following error:
import Utils from './utils'
^^^^^^
SyntaxError: Unexpected token import
In my packages.json i have babel-cli, babel-preset-env and babel-preset-es2015 defined. I have followed various blog posts and videos but still get same error.
ES6 is enabled in settings and i tried adding Babel file watch as per documentation but nothing seems to work. This feels like it should be a lot easier and just work, so i must be missing a important part of the jigsaw.
Does anyone have a working step by step, from fresh project, how to guide in configuring webstorm to work with import ?
Some places say use file watch, others say just to change project configuration interpreter to use babel-node. Other say must use Gulp... very confusing.
Thank you.
fLo
To make things clear: this is not about configuring WebStorm, error comes from Node.js interpreter that runs your code. Node.js still doesn't support ES6 modules natively (actually, no JavaScript runtime currently supports them - ECMAScript does not define a "Loader" specification which determines how Modules are inserted into the runtime. The Loader spec is being defined by WHATWG, but is not yet finalized). So, to get ES6 imports/exports accepted, you need using transpilers. Current industry standard is Babel
The most simple way to make it work is the following:
install babel in your project using npm install --save-dev babel-cli babel-preset-env
create a .babelrc file in project root dir:
{ "presets": ["env"] }
in your Node.js Run configuration, pass -r babel-register to Node:
With this configuration, your code will be transpiled on-the-fly by Babel, no file watchers, etc. are needed
I would like to add some features to gluon charm-down I am currently missing.
Too bad that no documentation exisits about how to do that.
All the steps I describe here are done on my development computer where I also develop a test-app using gluon mobile (incl. charm-down). Compiling/deploying this app I have no problem under iOS, Android, Desktop/Windows Surface.
My Development Environment is
Windows 10 /x64 Intel i7 32GB. Java 8u121 (some others too), installed Android SDK
For the iPhone I also have a Macbook here (which I do not use for development, only for compile/deployment/tests).
In order to be able to make my addons to charm-down I checked out the source from BitBucket via Mercurial.
hg clone https://bitbucket.org/gluon-oss/charm-down
Then I changed the working directory to the checked out root (with build.gradle, gradle.properties etc.) and called
gradlew clean install
After a short while I am informed that ANDROID_HOME is not set. Well, it is set, but as Windows Enviroment. To enable gradle to have it, I added it to gradle.properties (ANDROID_HOME=C:/.....)
The directory I gave is the one containing the directories (add-ons, build-tools etc.)
No more complaints from gradle about the missing ANDROID_HOME, but now I get compile errors for missing Android Classes
C:\projects\Gluon-Charm\charm-down\plugins\plugin-lifecycle\android\src\main\java\com\gluonhq\charm\down\plugins\android\AndroidLifecycleService.java:30: error: package android.app does not exist
import android.app.Activity;
^
C:\projects\Gluon-Charm\charm-down\plugins\plugin-lifecycle\android\src\main\java\com\gluonhq\charm\down\plugins\android\AndroidLifecycleService.java:31: error: package android.app does not exist
import android.app.Application;
^
C:\projects\Gluon-Charm\charm-down\plugins\plugin-lifecycle\android\src\main\java\com\gluonhq\charm\down\plugins\android\AndroidLifecycleService.java:32: error: package android.os does not exist
import android.os.Bundle;
.... many more
What am I missing ?
If you have a look at the core/android module's build.gradle file, there is a dependency on the android.jar:
dependencies {
compile project(":core")
compile files("$ANDROID_HOME/platforms/android-$androidPlatformVersion/android.jar")
compile "org.javafxports:jfxdvk:$javafxportsVersion"
}
You have already defined your ANDROID_HOME path, but there is another variable: $androidPlatformVersion.
This one is defined in the gradle.properties file that you will find in the root of the Charm Down project, with these two properties set:
androidPlatformVersion=24
javafxportsVersion=8.60.8
You'll need to install Android SDK 24, so the dependency is resolved and android.jar is added.
when I want to build my ember electron app with ember electron:package
I always get the error:
Build failed.
File: assets/vendor.js (91129:6)
The Broccoli Plugin: [UglifyWriter] failed with:
followed by several lines of "Error at...:" (always within node_modules)
I could figure out that it must have something to do with ember-browserify.
I am importing this node module in a service.js file:
import Usabilla from 'npm:usabilla-api';
The curious thing is, that with ember electron (like ember serve) everything is fine and I can use the node module without any errors. Issues only occur when I want to package the app to the .dmg and exe files for distribution.
What am I missing ?
Thanks for any help or hints!
Your build is failing on the minification step. Possibly because of the size of one of the packages you're pulling in or because it's already been minified. Minification only happens when you're building for production or packaging which is why you're not seeing the issue when you run locally.
From the EmberCLI docs on minification, where you'll find more on the minifaction step:
the js-files are minified with broccoli-uglify-js in the production-env by default. You can pass custom options to the minifier via the minifyJS:options object in your ember-cli-build
You can exclude specific files/resources that are causing problems:
To exclude assets from dist/assets from being minificated, one can pass options for broccoli-uglify-sourcemap
I just create the demo app in c drive and it's working perfectly.
Even though I have GOPATH properly set, I still can't get "go build" or "go run" to find my own packages. What am I doing wrong?
$ echo $GOROOT
/usr/local/go
$ echo $GOPATH
/home/mitchell/go
$ cat ~/main.go
package main
import "foobar"
func main() { }
$ cat /home/mitchell/go/src/foobar.go
package foobar
$ go build main.go
main.go:3:8: import "foobar": cannot find package
It does not work because your foobar.go source file is not in a directory called foobar. go build and go install try to match directories, not source files.
Set $GOPATH to a valid directory, e.g. export GOPATH="$HOME/go"
Move foobar.go to $GOPATH/src/foobar/foobar.go and building should work just fine.
Additional recommended steps:
Add $GOPATH/bin to your $PATH by: PATH="$GOPATH/bin:$PATH"
Move main.go to a subfolder of $GOPATH/src, e.g. $GOPATH/src/test
go install test should now create an executable in $GOPATH/bin that can be called by typing test into your terminal.
Although the accepted answer is still correct about needing to match directories with package names, you really need to migrate to using Go modules instead of using GOPATH. New users who encounter this problem may be confused about the mentions of using GOPATH (as was I), which are now outdated. So, I will try to clear up this issue and provide guidance associated with preventing this issue when using Go modules.
If you're already familiar with Go modules and are experiencing this issue, skip down to my more specific sections below that cover some of the Go conventions that are easy to overlook or forget.
This guide teaches about Go modules: https://golang.org/doc/code.html
Project organization with Go modules
Once you migrate to Go modules, as mentioned in that article, organize the project code as described:
A repository contains one or more modules. A module is a collection of
related Go packages that are released together. A Go repository
typically contains only one module, located at the root of the
repository. A file named go.mod there declares the module path: the
import path prefix for all packages within the module. The module
contains the packages in the directory containing its go.mod file as
well as subdirectories of that directory, up to the next subdirectory
containing another go.mod file (if any).
Each module's path not only serves as an import path prefix for its
packages, but also indicates where the go command should look to
download it. For example, in order to download the module
golang.org/x/tools, the go command would consult the repository
indicated by https://golang.org/x/tools (described more here).
An import path is a string used to import a package. A package's
import path is its module path joined with its subdirectory within the
module. For example, the module github.com/google/go-cmp contains a
package in the directory cmp/. That package's import path is
github.com/google/go-cmp/cmp. Packages in the standard library do not
have a module path prefix.
You can initialize your module like this:
$ go mod init github.com/mitchell/foo-app
Your code doesn't need to be located on github.com for it to build. However, it's a best practice to structure your modules as if they will eventually be published.
Understanding what happens when trying to get a package
There's a great article here that talks about what happens when you try to get a package or module: https://medium.com/rungo/anatomy-of-modules-in-go-c8274d215c16
It discusses where the package is stored and will help you understand why you might be getting this error if you're already using Go modules.
Ensure the imported function has been exported
Note that if you're having trouble accessing a function from another file, you need to ensure that you've exported your function. As described in the first link I provided, a function must begin with an upper-case letter to be exported and made available for importing into other packages.
Names of directories
Another critical detail (as was mentioned in the accepted answer) is that names of directories are what define the names of your packages. (Your package names need to match their directory names.) You can see examples of this here: https://medium.com/rungo/everything-you-need-to-know-about-packages-in-go-b8bac62b74cc
With that said, the file containing your main method (i.e., the entry point of your application) is sort of exempt from this requirement.
As an example, I had problems with my imports when using a structure like this:
/my-app
├── go.mod
├── /src
├── main.go
└── /utils
└── utils.go
I was unable to import the code in utils into my main package.
However, once I put main.go into its own subdirectory, as shown below, my imports worked just fine:
/my-app
├── go.mod
├── /src
├── /app
| └── main.go
└── /utils
└── utils.go
In that example, my go.mod file looks like this:
module git.mydomain.com/path/to/repo/my-app
go 1.14
When I saved main.go after adding a reference to utils.MyFunction(), my IDE automatically pulled in the reference to my package like this:
import "git.mydomain.com/path/to/repo/my-app/src/my-app"
(I'm using VS Code with the Golang extension.)
Notice that the import path included the subdirectory to the package.
Dealing with a private repo
If the code is part of a private repo, you need to run a git command to enable access. Otherwise, you can encounter other errors This article mentions how to do that for private Github, BitBucket, and GitLab repos: https://medium.com/cloud-native-the-gathering/go-modules-with-private-git-repositories-dfe795068db4
This issue is also discussed here: What's the proper way to "go get" a private repository?
I solved this problem by set my go env GO111MODULE to off
go env -w GO111MODULE=off
Note: setting GO111MODULE=off will turn off the latest GO Modules feature.
Reference: Why is GO111MODULE everywhere, and everything about Go Modules (updated with Go 1.17)
GO111MODULE with Go 1.16
As of Go 1.16, the default behavior is GO111MODULE=on, meaning that if
you want to keep using the old GOPATH way, you will have to force Go
not to use the Go Modules feature:
export GO111MODULE=off
In the recent go versions from 1.14 onwards, we have to do go mod vendor before building or running, since by default go appends -mod=vendor to the go commands.
So after doing go mod vendor, if we try to build, we won't face this issue.
Edit: since you meant GOPATH, see fasmat's answer (upvoted)
As mentioned in "How do I make go find my package?", you need to put a package xxx in a directory xxx.
See the Go language spec:
package math
A set of files sharing the same PackageName form the implementation of a package.
An implementation may require that all source files for a package inhabit the same directory.
The Code organization mentions:
When building a program that imports the package "widget" the go command looks for src/pkg/widget inside the Go root, and then—if the package source isn't found there—it searches for src/widget inside each workspace in order.
(a "workspace" is a path entry in your GOPATH: that variable can reference multiple paths for your 'src, bin, pkg' to be)
(Original answer)
You also should set GOPATH to ~/go, not GOROOT, as illustrated in "How to Write Go Code".
The Go path is used to resolve import statements. It is implemented by and documented in the go/build package.
The GOPATH environment variable lists places to look for Go code.
On Unix, the value is a colon-separated string.
On Windows, the value is a semicolon-separated string.
On Plan 9, the value is a list.
That is different from GOROOT:
The Go binary distributions assume they will be installed in /usr/local/go (or c:\Go under Windows), but it is possible to install them in a different location.
If you do this, you will need to set the GOROOT environment variable to that directory when using the Go tools.
TL;DR: Follow Go conventions! (lesson learned the hard way), check for old go versions and remove them. Install latest.
For me the solution was different. I worked on a shared Linux server and after verifying my GOPATH and other environment variables several times it still didn't work. I encountered several errors including 'Cannot find package' and 'unrecognized import path'. After trying to reinstall with this solution by the instructions on golang.org (including the uninstall part) still encountered problems.
Took me some time to realize that there's still an old version that hasn't been uninstalled (running go version then which go again... DAHH) which got me to this question and finally solved.
Running go env -w GO111MODULE=auto worked for me
Without editing GOPATH or anything, in my case just worked the following:
/app
├── main.go
├── /utils
└── utils.go
Import packages where needed. This can be unintuitive, because it isn't relative to the app path. You need to add the app in the package path too:
main.go:
package main
import(
"app/util"
)
Being in app directory, run:
go mod init app
go get <package/xxx>
go build main.go / go run main.go
You should be good to go.
GOPATH = /home/go
appPath = /home/projects/app
Create a proper go.mod and go.sum with go mod init app (delete old before)
After that resolve all dependencies like missing packages with go get github.com/example/package.
In simple words you can solve the import problem even with GO111MODULE=on with the following syntax for import:
import <your_module_name>/<package_name>
your_module_name -> module name which can be found in the go.mod file of the module as the first line.
example: github.com/nikhilg-hub/todo/ToDoBackend
package_name -> Path to your package within module.
example: orm
So the import statement would look like:
import "github.com/nikhilg-hub/todo/ToDoBackend/orm"
According to me we need to specify the module name + package name because we may need a same package name in two or more different modules.
Note: If you are importing a package from same module still you need to specify the full import path like above.
If you have a valid $GOROOT and $GOPATH but are developing outside of them, you might get this error if the package (yours or someone else's) hasn't been downloaded.
If that's the case, try go get -d (-d flag prevents installation) to ensure the package is downloaded before you run, build or install.
GOROOT should be set to your installation directory (/usr/local/go).
GOPATH should be set to your working directory (something like /home/username/project_folder).
GOPATH should not be set to GOROOT as your own project may need to install packages, and it's not recommended to have those packages in the Go installation folder. Check out this link for more.
For me none of the above solutions worked. But my go version was not the latest one. I have downloaded the latest version and replaced the older version in my mac os after that it worked perfectly.
I had a similar problem when building a docker file:
[1/3] STEP 9/9: RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -o manager main.go
api/v1alpha1/XXX.go:5:2: cannot find package "." in:
/workspace/client/YYY/YYY.go
This only appeared when building the Dockerfile, building locally worked fine.
The problem turned out to be a missing statement in my Dockerfile:
COPY client/ client/
I do not understand why this happens, we must be able to import from wherever our file is in its nest, since I have discovered that if we have more than one nest this will throw an error.
package main
import (
"fmt"
"indexer/source/testPackage3" // this will be show a GOROOT error.
"indexer/testPackage"
"indexer/testPackage2"
)
func main() {
fmt.Println("Agile content indexer -")
fmt.Println(testPackage.Greeting())
fmt.Println(testPackage2.Greeting())
fmt.Println(testPackage3.Greeting())
}
├── testPackage2
│ ├── entry2.go
│ └── source
│ └── entry3.go
To conclude, I just want to tell you, the entry3.go file will not work when imported into my main file, which in this case is (main.go), I do not understand why, therefore, I have simply chosen to use a depth folder in the packages I need to export.
entry.go, entry2.go will work perfectly when imported, but entry3.go will not work..
In addition, both the directory and the name of the package must be the same so that they work properly when importing them.
Have you tried adding the absolute directory of go to your 'path'?
export PATH=$PATH:/directory/to/go/