Allow all configuration options of livereload to be passed through.

[aknrdureegaesr]

Allow all [livereload]() configuration options to be passed through.

Fixes #100

[jsf-clabot]

All committers have signed the CLA.

[XhmikosR]

@aknrdureegaesr Can you reduce duplication a bit? hostname: options.hostname is set in both cases.

Also can you add a test?

[aknrdureegaesr]

I have been looking for the test to augment by temporarily introducing a bug in the existing passing of the parameters:

        // Inject live reload snippet
        if (options.livereload !== false) {
          middleware.unshift(injectLiveReload({port: 35729, hostname: 'localhost'}));
          callback(null);
        } else {
          callback(null);
        }

When I run npm test, all tests still pass.

Is there any other way to run tests, or does a test that tests parameter passing simply not exist presently?

[XhmikosR]

The tests are here https://github.com/gruntjs/grunt-contrib-connect/blob/9da2f3788a1b61b368562e6c879d1dfd292f0057/test/connect_test.js#L193-L218

You could add a new test there, pass your options and check if the port/hostname etc match.

[aknrdureegaesr]

There are three code branches:

• options.livereload is true
• options.livereload is a number
• options.livereload is a map.

The redundant hostname: options.hostname is only set in two of the three.

[XhmikosR]

The redundant hostname: options.hostname is only set in two of the three.

Yeah, but still, it's duplication.

[aknrdureegaesr]

Yes, I've seen those tests. Those tests do not test whether the number passed as a port is actually used, so they test something, but not parameter handover.

I take your answer as "tests that test parameter passing do not presently exist".

I'll see what I can do.

[aknrdureegaesr]

The way to avoid it I can think of is something like

        if (options.livereload !== false) {
          if (options.livereload === true || typeof options.livereload === 'number') {
            ...
            if (options.livereload === true) {
              ...
            } else {
              ...
            }
          }

Seems to me that cure is worse than the disease. What do you think?

[XhmikosR]

OK, let's forget about the deduplication, but please try to add a test.

[aknrdureegaesr]

OK, let's forget about the deduplication, but please try to add a test.

Done.

[XhmikosR]

So, @aknrdureegaesr, thanks for the patience so far!

Now, I was wondering, the 2 tests you added do seem indentical in the objects you are passing. Do we need them to be like that or should we test for different things?

[aknrdureegaesr]

At this point, we have three cases: Livereload is simply true, or is a number, or is an object. The possibility to add an object is new. The other two configuration options existed before.

As I found out, there was no previous test for the "number" case. There was only a test on the "true" case.

So I added that missing test for the previously-existing "number" functionality. And I also added a test for my own work. So we now have three tests instead of one. The two new tests very closely model what had been done in the previously existing test.

But...

I am not so sure the previously existing functionality is actually useable. At least on my machine, in a real-world example, both variants (true and number) kept producing a script URI along the lines of http://0.0.0.0:port/.... My browser could not successfully fetch a script from 0.0.0.0. The patch I present here is helpful, as it allows to precisely determine the URI.

It might be worth a consideration to simply remove the old "true" and the old "port" configuration. There is nothing you could do with those that you couldn't do with the full way, that my patch introduces.

But it might break compatibility for people who have been using the old way and for whom that worked. I'm not sure whether such people exist or don't. Those people would have to re-configure.

In short: To reduce code and tests, we could remove the two old ways, "true" and number, and only keep my new way. I'd be happy to reduce the code in that way.

What do you think, is better? Small, or compatible?

[XhmikosR]

Let's keep the changes to the minimum here and you can always make a new PR to improve tests later.