available browser info module idea

idea.md

There are several modules that do the following:

1. locate available browsers on the current machine;
2. do something with that information.

Usually #2 is "launch the browser with some specific content", but not always.

The modules I have in mind (of course there may be more!) are:

• testem
• browser-launcher
• launchpad
• karma-detect-browsers

What I noticed is that each of these modules hosts a similar set of information about how to find browsers and parse versions on different platforms. See:

• https://github.com/airportyh/testem/blob/master/lib/browser_launcher.js
• https://github.com/substack/browser-launcher/tree/master/lib
• https://github.com/ekryski/launchpad/tree/master/lib/local/platform
• https://github.com/litixsoft/karma-detect-browsers/tree/master/browsers

That means that each of them has to maintain their information sets independently. Meanwhile, if another module comes along that wants to do something different with available local browsers, it will have to reproduce the information set in its own way.

I wonder if that information set could be pooled into a shared module? Everybody would get the accurate info; if a bug like "Doesn't find Firefox on Windows..." is fixed in the shared module, everybody benefits; and new modules could use it to whatever ends they want.

If not sure if the module should just be an object of information or if it should also have some functionality. Seems plausible to me that each plugin would want to independently control how it uses the information to actually find (and probably run) the browser (?).

At least one problem: I have no idea how to make automated test this kind of thing.

If the data is separate from functionality, one potential problem I can see come up is inadvertently introducing bugs to the code downstream. Since each user of the module is responsible for making use of the data - and therefore each could use it a slightly different way, you could get into edge cases where the metadata works with say testem's way of launching browsers but is breaking launchpad. The only way to prevent that is to run the test suites for all "supported" users, assuming they have tests associated with launching browsers.

I guess would make sense is a shared module to get the list of installed browsers, including some informations like exact version or path to executable an so on. But the start/launch of the browsers should be up to the consumer of the module. So the module don't have to care about. An ideally each browser is a own module. They just need to exposes the same api. This would be kind of what the karma test runner does to launch the browsers (http://karma-runner.github.io/0.12/config/browsers.html)

@airportyh: I wonder what kind of bug that could be ... seems that the goal would be to include only the information that everybody trying to locate a browser on a system would need, while any other information that is specific to one module and might upset other modules would be kept out?

@4kochi: Maybe just need to add to the list already started with:
https://github.com/hughsk/chrome-location
https://github.com/hughsk/firefox-location

Started work here https://github.com/davidtheclark/locate-browsers — along with its supporting browser-specific modules.