Rendering triggers an error with `hlx up`

[kptdobe]

To reproduce:

1. Build and link hlx-cli latest master.
2. Run:

hlx init testproject
cd testproject
hlx up

3. Open http://localhost:3000/index.html

-> Error:

[hlx] error: Error while delivering resource: Error: Cannot find module '@adobe/htlengine/src/runtime/Runtime'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)
    at Function.Module._load (internal/modules/cjs/loader.js:475:25)
    at Module.require (internal/modules/cjs/loader.js:598:17)
    at require (/Users/alex/work/dev/playground/project-helix/modules/helix-cli/node_modules/v8-compile-cache/v8-compile-cache.js:159:20)
    at newRequire (/Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:36:18)
    at localRequire (/Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:54:14)
    at Object.parcelRequire.html.htl../html.pre.js (/Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:153:17)
    at newRequire (/Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:48:24)
    at /Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:80:5
    at Object.<anonymous> (/Users/alex/work/dev/playground/newhelixproject/alexproject/.hlx/build/html.js:106:3)

[kptdobe]

When using npm install -g @adobe/helix-cli to install the client I get another error...:

[hlx] error: Error while delivering resource: TypeError: mod.main is not a function
    at executeTemplate (/Users/alex/.nvm/versions/node/v9.11.2/lib/node_modules/@adobe/helix-cli/node_modules/@adobe/petridish/src/HelixServer.js:36:30)
    at <anonymous>

[kptdobe]

2nd issue: no html.js is generated, adding @adobe/parcel-plugin-htl to the dev dep of testproject fixes the issue. But @tripodsan mentioned this could be removed... not sure if this really works without.

[trieloff]

@davidnuescheler mentioned something similar yesterday. Haven't been able to look into it, yet.

[tripodsan]

should work...let me check

[tripodsan]

the problem is that the node_modules of helix-cli is not visible from the html.js that is executed via petridish. the search path for require is for example:

/Users/tripod/helix/examples/soupdemo/.hlx/build/node_modules
/Users/tripod/helix/examples/soupdemo/.hlx/node_modules
/Users/tripod/helix/examples/soupdemo/node_modules
/Users/tripod/helix/examples/node_modules
/Users/tripod/helix/node_modules
/Users/tripod/node_modules
/Users/node_modules
/node_modules
/Users/tripod/.node_modules
/Users/tripod/.node_libraries
/data/nvm/versions/node/v8.11.3/lib/node

there are 3 solutions to this problem:

1. bundle all dependencies that are directly required by the compiled scripts into the script
2. run the script in a location that has access to all the modules, e.g. in a dedicated helix sandbox
3. add helix-cli/node_modules to the search path for require() for the script

I think that 1) is the most robust as it fixes the version of the pipeline with the code of the compiled script. this allows to have a more lightweight openwhisk containers that don't depend on the helix modules.

[trieloff]

I'm not sure I'd favor option (1) as it slows down deployment and makes it harder for us to centrally update the core pipeline. I don't see the size of the OpenWhisk container as that big of an issue.

[tripodsan]

...centrally update the core pipeline.

which is probably a nightmare.... helix-cli-v1.X together with customer pre.js-v2.Y runs with openwhisk-helix-container-v3.27.Z which contains pipeline-v4 etc....

[trieloff]

Or: you always get the latest default pipeline upon invocation. If you want to fix a certain pipeline, you override it.

I would not want to give customers choice over the container they are running, but I also don't want customer code to go stale.

Given that we will have access to customer code (including hlx test) we can make sure pipeline upgrades are non-breaking.

[tripodsan]

1. parcel can't include dependencies if they are not declared in the projects package.json. I guess this is obvious, since they come indirectly via the plugin
2. parcel trips over:

[hlx] info:     buildDir: /Users/tripod/helix/examples/soupdemo/.hlx/build
🚨  /Users/tripod/helix/examples/soupdemo/node_modules/@adobe/openwhisk-loggly-wrapper/transport.js:19:40: Unexpected token (19:40)
  17 |   constructor(options) {
  18 |     super(options);
> 19 |     this.loggly = loggly.createClient({ ...options, bufferOptions: { size: 1 } });
     |                                         ^
  20 |   }
  21 |
  22 |   log(info, callback) {

so we probably want to add the @adobe/hypermedia-pipeline to the package.json of the project. it might make sense, since we mimick the production enviroment. so option 4)