So I've been trying to install gulp and I keep getting:
module.js:471^throw err : cannot find module 'C:\c\Users\Joe's Steezy
Laptop\AppData\Roaming\npm\node_modules\gulp-cli\bin\gulp.js'
As you can see my username has spaces in it and I read that npm cant read paths that have spaces. my question is how do i fix this? I know theres the option to do symbolic links, and there is an option to make a whole new user and make sure the username folder doesn't have any spaces in it this time.
Is there another way I can do this? I don't trust myself enough to do a symbolic link because i read that it can really mess up your system if you mess it up. I also don't really want to make a whole new user on my laptop because then i have to install all my programs all over again which kind of sucks. Please if anyone can help, it would be much appreciated!
This works for windows. You can use the short path name in the environment variable, e.g. use "C:\PROGRA~1\nodejs" instead of "C:\Progam Files\nodejs".
You can find out the correct short name of your folder by executing dir /x in the parent folder.
This is for those who all are facing the issue and didn't get any workaround. What you can do is change the cache path using below command:
npm config set cache "C:\Users\FirstName~1\AppData\Roaming\npm-cache" --global
Here FirstName is path name which includes spaces between them.
Related
We have a script "build": "rollup -c rollup.js --environment production", which when called by some of our team (who use Windows) will on occasion spontaneously not run as normal, but instead just open up the rollup.js config file in an editor. Unfortunately I don't really know where to start with this because I've never been able to replicate it. No logfile is being produced and as far as I've been told ignore-scripts is not set, which are the only other things I've seen related to this behaviour on SO.
Is this a known thing that there's a simple fix for? Or if not, where should I go to find more info about this? Would this be an issue with npm, or with rollup?
I encunter the same sutiation on Windows.
I bypass it by using WSL.
Through some investigating I've tracked this down to what I believe to be a rollup bug with regards to how they're processing their config files. I feel as though I should open a ticket with them regarding this but I've been acting on behalf of a team member and don't have the ability to replicate it on my own, so... I suppose I'll try and coerce them into doing it.
But anyways, so from what I can tell looking at rollup's source, if a rollup config file has a plain .js extension, then it looks as though rollup is running itself on the config to convert it into a CommonJS format, which it will then import and use on the actual build step. Somewhere in this process on Windows something goes awry and the result is that the config file just ends up getting opened with whatever the default handler is for JS files. So basically the solution is to change the file extension.
Our original config was set up using ES6 import/export, and I'm unclear at this point whether changing the extension to .mjs will skip or otherwise change this conversion step, it seems to have worked as such when people have tried it but I can't vouch for it. What I did was to instead go through the config and manually convert all the ES6 import/exports to CommonJS require() and then change the file extension to .cjs (hence our config changed from rollup.js to rollup.cjs) and now it appears to be working consistently across the board.
Total Linux noob here. I am trying to configure a Pleroma development environment on DO droplet. Installed LEMP, installed SSL, installed PostgreSQL, installed Pleroma, so far so good.
Then I installed Node, NPM, cloned Pleroma-FE (apparently it installs in /user/pleroma-fe folder). I am following the very brief build instructions here:
https://git.pleroma.social/pleroma/pleroma-fe
When I get to the command in those build instructions: npm run build
I am getting error: Error: Cannot find module '/user/build/build.js'
It's because actual path to the build file is /user/pleroma-fe/build/build.js
Apologies if this is a duplicate. I see other questions about this.
Fixing npm path in Windows 8 and 10
and the reply seems to set the PATH. This answer might apply to my situation. But my question is: it is clearly already looking in a well defined path (which is different from all the other questions, which don't seem to have well defined path in the error message). But it is the wrong path. How do I make it look in the correct path?
I tried the npm command and specified the complete path, and every variation. and none worked. So it seems fixing the path won't fix this problem.
Sorry I do not currently know enough Linux to be able to fix this. I tried to tag this with Pleroma but I don't have enough reputation to create a new tag. Any help is much appreciated. Thanks in advance.
I continued to work on this with some help of a Linux admin on Fiverr and the Pleroma developers chat with success, thanks to all.
The solution did not involve changing the path. There were several different things going on. First, I needed to change directory into the development project source folder:
cd pleroma-fe
Once I did that, npm found the build module. Next issue was Node was very old and I needed to get the latest version. I used the instruction here for NodeJS (10):
https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions
Next issue was npm was missing some modules. This was fixed with:
npm install
After that the build completed with no errors.
npm run build
After a successful build, you will see a list of files that have changed as a result of the build.
Next issue is that simple changes in HTML text were not live, ie. not reflected in the refreshed web page. This is fixed by copying all the resulting build files to the production folder using rsync. In my case the command was:
rsync -av /user/pleroma-fe/dist/ /home/pleroma/pleroma/priv/static/
Pleroma is a neat Twitter-like user interface to ActivityPub fediverse, it includes a Mastodon UI as well, and thanks to the developers for making it free and open source.
About a week ago I installed golang successfully on my computer and got it's terminal commands to process. So by that, I know go is on my computer.
I have been looking for a good IDE and found https://code.google.com/p/liteide/ LiteIDE which was made specifically for Go.
I read that if you already had go installed on your computer then you could use LiteIDE to start building your code right away. I must have read something wrong some where because I cannot get my projects to build at all. I think it there may be a missing/incorrect path and or something is just setup incorrectly.
This is the error I get in the console:
Current environment change id "win64-user"
C:/go/bin/go.exe env [c:\go]
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GORACE=
set GOROOT=c:\go
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set TERM=dumb
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CXX=g++
set CGO_ENABLED=1
Command exited with code 0.
First_Lite_Go_Proj [C:/go/src/First Litel Go Proj]
Error: process failed to start.
I checked the C:/go directory to make everything there is correct and it was. Also I'm using 64bit windows 7 and double checked that as well.
Any ideas? Mine are: Missing/Incorrect Paths, Can't access a certain directory due to restrictions.
While I have not tested this in Windows 7, on Windows 10, these were the steps that I took to make LiteIDE work
Installed Go to C:\Go
Added C:\Go\bin to PATH and made sure go was working from Command Line
This was the most important step for me. Defined GOPATH in an environment variable. In my case, it was C:\Users\vivek\Documents\Source\Go. I also made sure that there were three folders src, pkg and bin were created in GOPATH. At this point go env was showing me correct values for GOPATH and GOROOT. go get, go build and go install was working as well at this step.
Downloaded and unzipped LiteIDE to C:\liteide. Started LiteIDE and it worked out of the box for me. Make sure that GOPATH is seen correctly by LiteIDE by going to View > Manage GOPATH
Hope this helps. Good luck.
It's not a good idea to keep your projects in the GOROOT path, which per default (when installed using the MSI installer) is C:\Go. Always keep it separated from there. It also helps to avoid issues with updates.
Since Go projects are made up of packages which are organized in directory structures it is important to follow a few rules and keep the working space for your Go projects separated and clean.
In my opinion its best practice to create ONE working directory as the root for ALL your Go projects somewhere in your user space and stick to it.
One way to do this is to create a directory like "work" and set the environment variable GOPATH to it (e.g. C:\Users\Peter\Documents\work). Make sure to relog or restart your computer after your changes.
Upon certain operations Go will automatically create the directories bin, pkg and src below your GOPATH.
src contains your created or downloaded Go source files,
pkg contains your installed package objects, and
bin contains your installed executable files.
bin or pkg will automatically be created when you use the go install command to install a binary executable or a package. It's important to understand that these are files that are not part of the Go installation.
src, if it does not yet exist, will automatically be created the first time you issue a go get command or in case of LiteIDE, the first time you create a new Go1 Command Project or Go1 Package Project. Watch the "Location:" field on the dialog box, it should include your path defined in GOPATH followed by \src (e.g. C:\Users\Peter\Documents\work\src).
In the name field enter the path you want to use for your project. If you plan to track the development of your project on Github (or other repo) it's common practice to include the path to the Git repo in your source path (e.g. github.com/petergloor/hello-go).
Of course you can use any other structure to organize your projects as long you make sure they fall below the src directory in your GOPATH.
For more information about Go workspaces read https://golang.org/doc/code.html#Workspaces.
A final note about the GOROOT environment variable. Dont explicitly set this if you install Go in C:\Go. It's enough to include C:\Go\bin in your path and to set GOPATH. GOROOT is only needed in case Go is installed at another location.
I also had this problem first, but after completing the installation process, I succeeded.
Step 1:
Run (Ctrl+R) -> run target, request build first.
BuildAndRun(Ctrl+F7) -> build and run target
FileRun(Alt+F6) -> go run
step 2:
Check Config via this URL:
https://www.goinggo.net/2013/06/installing-go-gocode-gdb-and-liteide.html
Try setting up the GOROOT to the directory where go was installed. It worked for me.
Do you have 'Install' keyword in your project name? Try remove it.
You have to setup LiteIDE variables correctly (if there are not by default).
Please, check two options:
Go to Settings → "Manage GOPATH"
Options → LiteEnv (there are
environment definitions files). Just double click on someone and
setup Go environment variables.
I'm not sure how this works, but it worked in my case. I got this idea from this video on Youtube-Chris Hawkes
Open LiteIDE.
Click File---New.
Select "Go1 Command Project".
Browse the desired path.
Select the desired folder.
Name the folder and click Ok.
Now, you will be able to see a "main.go" file opened in the IDE.
Write whatever code you want to run in this file with correct syntax, it will run.
The only problem with this is, whenever I create another ".go" source code file in the same folder, the same error is shown. So, you might have to edit this file every time, you try to write new code.
I have a problem with Trac.
I cant create a new project.
Here, in the /path/to/myproject - what should I write instead of it?
In fact, my project path is: C:\Users\Programmer\BitNami Trac Stack projects
Everytime it outputs error in BitNami Trac Stack command line.
Why cant I create a new project?
It is writing: The system cannot find the path specified
Thanks!
try this:
cd C:\Users\Programmer\BitNami
trac-admin . initenv
You could save yourself a lot of hassle by avoiding blanks/spaces (and non-ASCII characters) in paths, at least if you expect to go to the command line. This always tends to become a pain.
Therefore reinstalling is a real option, because I know you can change path defaults to saner values without blanks/spaces. I did this before, and it works.
In your case to create a new project, use:
trac-admin c:/Users/Programmer/BitNami initenv
I've been trying to submit my app to the mac app store and I've been trying to figure out how to solve this issue:
Files Only Readable By The Root User - The installer package includes files that are only readable by the root user. This will prevent verification of the application's code signature when your app is run. Ensure that non-root users can read the files in your app.
I haven't been able to fix this problem for a while and does anyone have a solution?
In my case, none of the files were owned by root, but one had no read permissions for group and everyone, but only for my user. I found this by using this cmd in Terminal:
ls -lR /path/to/app
I then searched for "-----" inside the output from the ls command, which found the problematic file.
I had the same problem, but my solution was to run:
cd myApp.app
chmod a+rX *
This fixes the permissions and makes the Application Loader happy.
I found the answer:
I deleted some files that weren't readable by the system, files that showed a white blank icon
For anyone who has been banging their head on this one my experience is the error is erroneous or at best very misleading.
After looking over all the permissions then dragging files in and out of the bundle to test Application Loader the error magically disappeared and the same files with the same permissions ceased to give the same error.
This really isn't a solution but it may be important to know that this error may not be what it seems (tested on 10.9.4).