Beginner - IDE Stuck in Root Directory via FTP

So, I’m just starting in node.js. I’m using an CentOS box in AWS to host the meteor server and attempting to use PSPad to FTP into the directory and edit the files. This is less of a meteor question and more in the realm of Linux and permissions but I figure someone probably ran into this in the process of setting up their development workstation. With Filezilla I can FTP into all directories and view the HTML, .js, etc. files for my app. However, when I FTP in with PSPad or Notepad++ using the nppFTP plugin I can only view the root directory. I’m not sure why this is and I’m still fairly new to Linux. I did set the file owner to the account I am logging in with. Any help would be greatly appreciated.

Not sure why you’d need to ftp into the server, as that is typically where the meteor bundle lives, not the code you are actually editing that goes into the bundle.

I’m just using FTP for the purpose of having an IDE over a basic text editor. I’m attempting to access the directories that contain my files that the meteor server is actually hosting so that I can edit in a simpler environment. I installed meteor into /var/foldername/myapp. This is also where my actual files that the service is running are stored. What I’ve noticed is that I can’t access any sub-directories outside of root. So /var shows a blank listing except for the parent directory. However, in Filezilla I can successfully access /var/foldername/myapp/client/main.html and my other files. These files were installed with Meteor I believe.

Well there are two issues here – the first is that you are having trouble accessing the directories in your ftp connection. Not sure what flavor of linux you’re on, but in Ubuntu, I can just connect to server, and then browse those files in any application.

The second is that I’d say it is atypical to actually host/edit the meteor files on the server where you are hosting the app. You should install meteor on your local machine, edit the files there, and then deploy the bundle to the remote server, where you want to host the app. Does that make sense?

What development environment are you coming from? It sounds like it might be a pure scripted environment, like PHP, where coding on a central server expedites the process (especially if you’re solo).

I think you’ll find working with compiled (or partially compiled) environments like Node, you’ll want to adopt a local dev strategy. @vigorwebsolutions talks more about it above.

If you’re working on multiple machines, you’ll want version control. I use BitBucket for private repos.

Yes, that makes sense. I’m using FTP so that I can make changes and see them in real time as opposed to editing the files locally and sending the changes to the server. I made an error when I said Ubuntu. I’m using CentOS 6.8 for hosting. I’m using a remote box for hosting the app purely for scientific purposes. I could probably build a local environment for meteor on a VM but you can’t learn in your comfort zone, right? I’m in college and this is a project I took in my spare time to attempt to build a tech blog and portfolio as well as get some hands on experience with node.js and AWS. I’ve heard that rsync might be an option for editing the files locally and sending changes to the server. Is that something you would recommend?

This is a project I took in my spare time to build a tech blog and portfolio as well as experiment with node.js and AWS so I am 100% solo and working from only one physical machine.

I’m just guessing, but the way you’re talking makes it sound like you may come from a LAMP background, where in many cases, it is actually easier to ftp/ssh into your server and make changes there, rather than setting up a local environment and pushing changes from there.

With meteor, though, all you need to do is install meteor on your local machine, and you can run a developer environment with the meteor command in your app directory. This will run your app a non-minified version of your app on your local machine, which you can access at http://localhost:3000 (unless you choose to override those settings).

While that command is running on your local machine, any updates you make to the code will automatically be processed, and you will see the changes immediately in a refresh of your browser, pointed at http://localhost:3000. When you’ve made all the changes you want to, you would then invoke whatever deployment strategy makes sense. Could be MUP, galaxy, or just using meteor build to get a bundle that you can write a script for.

Again, I’m not saying you can’t host the meteor installation, make changes to your files there, and run the actual meteor command on your remote server, I’m just saying that the people behind meteor have gone to pains to make things so that you don’t have to do things that way, as developing on a local machine is much quicker, easier, etc.

2 Likes

That makes a lot of sense. I’m not personally from a LAMP background but the mentor who gave me advice when setting up this project definitely is. I can’t really claim to be from any discipline as I am still fairly new to this. I think I’ll try the local setup route to simplify things, especially while I’m still learning. I still have the hurdle of actually learning to be proficient in node.js after all. Thanks for the advice. Much appreciated.

1 Like