The server should not use a temporary file

[stof]

Currently, the server is generated dynamically by performing some string replacement in the JS codebase. This causes several issues or pain points:

• as the server will run from a temp folder, the normal node_modules resolution does not work (looking for it in parent folders), forcing us to configure the path explicitly all the time
• the server JS codebase is not valid JS, which confuses IDEs
• the JS codebase lives inside a PHP string, making it harder to see it.

I suggest refactoring the JS code to read the host and port from environment variables instead, allowing the server file to be a static file running directly from the ZombieDriver codebase (using a temporary folder only if the driver is included in a phar, as we need to copy the JS file outside the phar to make it available for node). This would mean that installing zombie in a project may be simpler: composer require behat/mink-zombie-driver --dev && npm install zombie --save-dev. As the node_modules folder will end up at the root of your project, which is a parent of vendor/behat/mink-zombie-driver/, the normal node module resolution algorithm will work fine for this case. Configuring the node_modules path will then be necessary only for people using a different project structure (but we can recommend this simpler one).

On a side node, maintaining the server as a node.js project means we will also be able to split it among multiple files (using require), which will become a must-have to implement the refactoring mentioned in #104 (putting everything in a single JS file would be hard to maintain, and even worse if this JS is actually inside a PHP Heredoc)

[aik099]

Then what currently is generated by createTemporaryServer would become a standalone project installable via NPM that driver can configure via ENV vars?

How do we preserve BC after these changes? User won't be able to specify alternative server code path anymore.

[stof]

@aik099 for now, I would keep it in there directly (having a server folder in the project or something like that), to avoid forcing everyone to install both the PHP library and the corresponding node library (and then having to deal with cross-compatibility between them because of separate versioning, and of harder testing as the driver testsuite would run the PHP library to actually cover logic implemented in the JS lib). We could imagine submitting it to NPM later in the future.