I have an old project with a folder structure like this:
and the new projects folder structure:
The server.go file looks like this starting with the old project:
and the new project:
I have the same GOPATH because I'm on the same computer at this exact time.
Why can I find the handlers and types folders from the old project but not from the new? I dont know if I'm doing anything different.
I get the new project working if I import the types and handlers folder by writing:
import ( "domain/handlers" )
where domain is the domain of my project and the root folder for this new project.
I can't import this way because when I deploy to GAE the program doesnt find my static folder if server.go resides in a subfolder..
thankful for any help in the right direction
Locations working for me (~/ is home folder):
~/go_appengine
~/Programming/golang_projects/bin
~/Programming/golang_projects/pkg
~/Programming/golang_projects/src
~/Programming/golang_projects/src/glassbackend/app.yaml
~/Programming/golang_projects/src/glassbackend/server.go
~/Programming/golang_projects/src/glassbackend/handlers/handler1.go
~/Programming/golang_projects/src/glassbackend/types/type1.go
In server.go:
import (
"types"
"handlers"
)
GOPATH = ~/Programming/golang_projects
Related
I am working on three projects(server, tv client and mobile client). They communicate through a web socket using message types. It's essential that message types should be consistent across the three projects. I've already setup git to manage the three projects within 1 root folder.
projectA // server project
projectB // tv client project
projectC // mobile react client project
shared-files <--- this is where i'd like to place any shared files ( in this case my message type constants )
At the moment i am stuck with importing outside assets to my react project.
I have tried by simply specifying the path to the file but react complains about importing assets outside src.
I also realized that when i do deploy my react app, the file wont be bundled so this wont work. My next idea was something along the lines of including the .js file as project dependencies thru an install but I have no clue how to do that. Have you done something like this yourself? any suggestions?
I do have an Electron + React project which I inherited from another developer.
in the index.js there are a couple of imports that WebStorm is saying it cannot find, however, the application compiles and works as needed.
and here is the structure of the folders relative to index.js
How do I make WebStorm happy and make it see the imports and navigate properly to them?
I tried to use exports section in the package.json like this
"exports": {
"./": "./src/"
}
but it didn't help.
Any other options?
Right-click on src directory and select Mark Directory as | Resource Root.
wondering if anyone can help me. Im following a tutorial which has told me to put the images in the public folder in an app created with create-react-app
'./img/newyork.jpeg'
this is the path the tutorial told me to use for images in the public folder however the images aren't loading and i cant understand why any help would be much appreciated
Build File Structure
You shouldn't keep any image assets in the public folder other than favicons etc See this thread also: The create-react-app imports restriction outside of src directory (TLDR: "This is special restriction added by developers of create-react-app. It is implemented in ModuleScopePlugin to ensure files reside in src/. That plugin ensures that relative imports from app's source directory don't reach outside of it.")
Generally in a create-react-app I would import images like so:
import lovelyImage from 'images/lovely-image.jpg'
and then rendered:
<img src={lovelyImage} alt={''} />
(the example above would assume the images directory is in the src directory (not public))
process.env.PUBLIC_URL + 'your image path'
is a solution I found that works
I have found numerous articles on StackOverflow and elsewhere stating that if you wanted to output your files to the bin folder using ClickOnce, you should set the
BuildAction: Content
CopyToOuputDirectory : Copy if newer
but some of my binaries are located in a Dependencies subfolder located in the root of my project and when I publish the content, they are being outputted to
<wpf app folder>\dependencies instead of being in the <wpf app folder> causing my app to not function properly.
Any suggestions on how I can change this to force ClickOnce to output specific files to <wpf app folder>\ irrespective of where the Source files are located.
I eventually found a work-around which I don't like but I need to move on. To circumvent this problem I added the required libraries to the root of my project as links and still set the BuildAction to Content and CopyToOutputDirectory to Copy if newer.
I thought I'd explain it with an example as it may make a bit more sense.
Project Path: C:\Work\MyApp and it contains the following sub-folders:
D:\Work\MyApp\MyApp.csproj
D:\Work\MyApp\MyApp.xaml
...
D:\Work\MyApp\Bin\Debug
D:\Work\MyApp\Bin\Release
D:\Work\MyApp\Bin\Release\MyApp.exe
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
etc...
The libraries are third-party tools and are actually contained in their own folder:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
By having the libraries in D:\Work\MyApp\Dependencies did not work as ClickOnce would install the app in:
C:\Users\\AppData\Local\Apps\2.0...\MyApp.exe
and it installed the files located in the Dependencies sub-folder in:
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibA.dll
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibB.dll
Which caused my app not to work.
To get around it, I ended up adding LibA.dll and LibB.dll to the root of my project as "Linked files" and set their BuildAction and CopyToOutputDirectory but not by pointing the linked files to
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
but instead pointing them:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
And this seems to have done the trick. My only beef about it is that now I've got 10 odd files listed in the root of my project in visual studio which I don't like:
MyApp Solution
- MyApp Project
- MyApp.csproj
- MyApp.xaml
- ...
- LibA.dll
- LibB.dll
- ...
But it will have to do for now.
Hope it helps others!
I am new to Go and AppEngine. I am trying to figure out how to create packages but I keep running into conflicts. My directory structure is below:
GOPATH
third-party-libs
app
app.yaml
controllers
default.go -- package controllers
models
models.go -- package models
templates
templates.go -- package templates
I am importing the templates package as follows import ("app/templates") inside default.go
When I do goapp serve I get this error:
Failed parsing input: app file templates.go conflicts with
same file imported from GOPATH
I have tried a bunch of things and nothing has worked so far. These are things I have tried:
Changed the templates directory to apptemplates and the corresponding file to apptemplates.go, changed package name to apptemplates. I imported it as app/apptemplates
I tried different combinations by changing the file name but not the package name, vice versa, etc. Either it does not find the file or has a conflict.
I am importing html/template in my templates.go file. So I commented out the entire file just keeping the package declaration but did not make the conflict go away
I thought may be another file is named templates.go but when I do this (at the GOPATH level) find . -name "*.go" | grep "templates.go" I only see the one file I have created.
I am confused as to how packages are created. I have changed the name to something generic so it does not look like a naming issue. Can someone please tell me how I can debug this error?
Thanks!
Rename the package to a non-conflicting name as in #1. Import the package using the path "apptemplates".
Packages inside of the application directory (the directory containing app.yaml) are imported with a path relative to the application directory. See Organizing Go Apps for the complete details.