Ability to manually specify port for Live Debugging to serve from

[ViViDboarder]

It seems that Live Preview Base Url is actually used for pointing to a url that is already being served. I'd like to specify a port range or port for Node to use.

[dangoor]

Right now, Brackets picks a random, available port to use for Node. I'm interested to know why you'd want to specify one, just so that we can have an idea of use cases behind features people want.

Thanks for the suggestion!

[ViViDboarder]

The actual use case I have is so I can do a reverse port forward and debug my Brackets app on my Android phone using Chrome Reverse Port Forwarding and Remote Debugging.

I'm not sure where the limit comes from, but Chrome is cutting me off at 4 digits and the random port is 5.

I tried to do it myself in a fork, but I can't figure out where Node is generating the port or how to specify it.

[dangoor]

@ViViDboarder I believe the port is set in the Server.js module of brackets-shell.

[peterflynn]

Is this unusual enough that it should be 'no priority'?

[dangoor]

@ViViDboarder Thanks for the details. We are planning to put some effort into rethinking how live development works generally. We can consider this need then.

[andoband]

@dangoor I'm working on an app that uses indexeddb and each time the live dev debugging port changes, i have to start with a fresh/empty indexeddb. It would be nice to be able to specify the port and not have it change so I can work across brackets sessions without losing my data. I did try manually setting the port in Server.js, but that didn't keep live dev from opening chrome with a random port.

[dangoor]

@andoband That makes sense. Thanks for the concrete use case. I added that to the research card about live development. With the new prefs system it may be possible to get a smaller update in to meet this need.

[andoband]

@dangoor Thanks. I really enjoy using Brackets (and being able to see how
you run your sprints).

On Mon, Jan 13, 2014 at 9:30 AM, Kevin Dangoor notifications@github.comwrote:

@andoband https://github.com/andoband That makes sense. Thanks for the
concrete use case. I added that to the research card about live
development. With the new prefs system it may be possible to get a smaller
update in to meet this need.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5626#issuecomment-32179074
.

[andoband]

@dangoor Not that you need more convincing, but I actually have another use case that is causing some pain. I am developing an app that uses the google drive api which uses oauth 2 and requires me to register the authorized origins for my javascript with their api console. Each time Brackets switches ports on me, I have to go into google's api console and change the port number there.

I know I could just fire up my own simple node server, but I've been too lazy.

[dangoor]

@andoband Yeah, I can see the uses. We just have a lot on our plates... we would accept a good pull request for this feature ;)

[andoband]

@dangoor I can do that. It looks fairly straight forward and would include small changes to a few files in the StaticServer extension. Additionally it would need to pull and sanitize a project-level pref which I haven't really looked into how to do yet. I know you're doing some work on the prefs system. There would need to be some tests, which I have yet to look into as well. Any recommendations before I undertake this?

[dangoor]

@andoband I have a pull request up for release 37 that will make project-level prefs a bit more explicit. But, there's not much of an API change required, really. It's more of an API addition.

PreferencesManager.get("livedev.port") can work today. In 37, PreferencesManager.get("livedev.port", PreferencesManager.CURRENT_PROJECT) will let you specifically restrict that setting to being a project-level setting (rather than one that changes file-by-file). The CURRENT_PROJECT style removes some potentially confusing cases where a user has a file open from another directory.

I don't know much about StaticServer and how it's tested yet. It's something I need to look into a bit soon anyhow. I'll let you know if I have more advice.

[andoband]

@dangoor FYI, I tried calling PreferencesManager.get("liveDevPort") in main.js of StaticServer.js extension, but the project file scope hadn't been loaded yet. So I moved the call inside AppInit.appReady() and it works there. A couple other extensions (JSLint, QuickView) do some prefs work in their main.js, and I'm wondering if we should expect the entire prefs system to be loaded and ready by the time the extensions main.js is executed.

[dangoor]

@andoband The difference with JSLint and QuickView is that JSLint is explicitly for the current file and QuickView is probably generally at the user level, but there's nothing stopping it from appearing at other levels. In both of those cases, they don't just get the value but instead listen for changes in the value.

The live development port isn't something that you'd really want changing while live development is running. It probably makes sense in this case to read the value at the time live development is started, if that works for the use case.

[andoband]

@dangoor Thanks Kevin, it makes sense what those other two extensions are up to. I was just caught off guard by the get() not working.

Say, I've placed the getting of this pref in main.js of the StaticServer extension and called it simply "liveDevPort". Even though StaticServer is technically an extension I don't use PreferencesManager.getExtensionPrefs(). It feels kind of dirty, but it was the simplest solution and it allows the user to just provide a "liveDevPort" value in their prefs versus "staticserver.liveDevPort". Any thoughts?

[dangoor]

Actually, what I'd probably go for is "staticserver.port". The reason I say this is that there's the distinct possibility that we will have other mechanisms for live development communication and "staticserver.port" is explicit about this being the port on which StaticServer is run. If StaticServer is not involved, then that setting has no relevance.

liveDevPort could potentially be confused with a port used for talking to the dev tools or a port used for doing live development with your own server (as in the "Project Settings" window).