Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

JavaScript

Posted by Doug Hawkinson
.a{fill-rule:evenodd;}techdegree
Doug Hawkinson
Full Stack JavaScript Techdegree Student 25,073 Points

Is there a way to programmatically make sure a port is shut down before listening on that port?

I am in the Tech Degree program. I am incrementally adding functionality and writing tests as I go. I am in the "test" environment when I run the tests. I am in the "development" environment when executing the real code. Both environments are running on localhost:5000. I just tracked down an unhandled error in my development environment:

Error: listen EADDRINUSE :::5000

My experience tells me, that specific error is thrown when the port is not available because something already has grabbed it.

Since I was playing earlier today in my "test" environment on localhost:5000 and then added some functionality on the "development" side and also tried to listen on on localhost:5000 that the error may be coming along because the port is still open from the earlier "test" runs. (Or, maybe I'm grasping at straws, I don't know).

I thought that I might be able to programmatically "kill" the port each time I begin a run (in either environment), and then start listening, after the kill, having freed the port. However, I don't know how to do that.

Does that sound like a plausible solution? How do I do it?

3 Answers

Doug Hawkinson
.a{fill-rule:evenodd;}techdegree
Doug Hawkinson
Full Stack JavaScript Techdegree Student 25,073 Points

For those following this thread, the solution came this way:

  1. I blew away the repo, so I could start over.

  2. I saved my workspace so I could reuse my code.

  3. I established a new workspace by using the Express Generator so I could get and industry-standard starting point. I did this because the original workspace, handed down in the project files was a hybrid build by the mentors that had some of the aspects of an Express generated project, mixed with non "vanilla" code.

  4. I then merged back in my working code from the original project.

The nest result is I no longer have the problems created by mixing my code with the original project files. Sometimes it is just best to start over with a clean slate.

Brendan Whiting
.a{fill-rule:evenodd;}techdegree seal-36
Brendan Whiting
Front End Web Development Techdegree Graduate 84,738 Points

How does it programmatically shut down a port?

Brendan Whiting
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Brendan Whiting
Front End Web Development Techdegree Graduate 84,738 Points
Brendan Whiting
.a{fill-rule:evenodd;}techdegree seal-36
Brendan Whiting
Front End Web Development Techdegree Graduate 84,738 Points

Here is a solution to this problem. In your app javascript file, you can set the value of the PORT to either an environment variable or a default:

index.js:

const { PORT=3000 } = process.env;

and this in my package.json I have a test script that's going to override that environment variable:

"test": "NODE_ENV=test PORT=3333 mocha --recursive --reporter spec"

So I'm saying in my app use port 3000 as a default if nothing is passed in as an environment variable, and then in my test script, explicitly set PORT to 3333, which will run the app on the other port when I run npm run test

I know this doesn't address the problem directly. There's probably a way to have a script that kills a process. But this is the practice that I've seen to solve this kind of problem.

Doug Hawkinson
seal-mask
.a{fill-rule:evenodd;}techdegree
Doug Hawkinson
Full Stack JavaScript Techdegree Student 25,073 Points
Doug Hawkinson
.a{fill-rule:evenodd;}techdegree
Doug Hawkinson
Full Stack JavaScript Techdegree Student 25,073 Points

Brendan:

That is a good solution and I thought about solving it that way. I may do that. The disadvantage that I thought about with that solution is the minor inconvenience of having to remember to open different instances of the browser to each port and the instance issue in Postman, which can of course, be dealt with by environments. I was hoping to find a foolproof way of programmatically "killing" the port and then "opening" it again. Nit picky, I suppose, and maybe not worth it.

I have a config.json file with, among other things, a PORT property, by environment. Perfect place to place the value. I may just do that and move on to my other challenges.

Thanks so much for the response. It helps me think through the issues.