Foxx: Module resolution will change in 2.8

[Alan Plum]

The implementation of the JavaScript `require` function will be adjusted to
improve compatibility with npm modules. The current implementation in 2.7 and
earlier versions of ArangoDB strictly adheres to the CommonJS module standard,
which deviates from the behaviour implemented in Node and browser bundlers.

Module paths will now be resolved in the following ways:

* relative paths (e.g. `./hello`) will be resolved relative to the current file
* absolute paths (e.g. `/hello`) will be resolved relative to the file system root
* global names (e.g. `hello`) will be resolved by looking in the following places:
  1. In a `node_modules` folder in the current directory
  2. In a `node_modules` folder in any ancestor of the current directory
  3. In the `js/node`, `js/server/modules` or `js/server/common` folders of ArangoDB
  4. In the internal `_modules` collection
  5. In the base folder of the current Foxx service or module

Prior to 2.8 global names and absolute paths are being treated interchangeably and
prioritize the service's (or module's) base folder, breaking compatibility with
some dependencies like `babel-runtime` (which has both a submodule `core-js` as
well as an npm dependency in `node_modules/core-js`).

Note that Foxx services generated with the web admin interface in 2.7 and earlier
use global names instead of relative paths and may need to be adjusted in order
to work with ArangoDB 2.8 and later.

You should not use global names to refer to local files within your Foxx service
(except for third party dependencies installed in the `node_modules` folder).
You can safely replace such names with the appropriate relative paths in your Foxx
code running on 2.7 and earlier.

[Gary Hai]

Why do not include 'lib' in manifest.json of foxx application?

[Alan Plum]

Hi Gary,

thank you for asking.

If you use the "lib" field in the manifest of a Foxx service, that folder will of course be used instead of the actual base folder.

Cheers,

Alan