suggest:

--browser

eg:

hlx up --browser

It should be relatively easy to run wsk action get --url for each code section specified in the yaml. And then warn that the strain is invalid if the URLs don't match.

hlx init should only create minimal example or even be removed completely.
More sophisticated examples can always be cloned from git.

eg:

$ hlx init my-test

+ creating my-test                 [ok]
+ creating my-test/index.md        [ok]
+ creating my-test/src/html.htl    [ok]
+ creating my-test/src/html.pre.js [ok]

Helix project 'my-test' initialized successfully with a simple example.
For more examples, clone or fork one from http://github.com/adobe/project-helix/.

Next Step: start the development server and test the generated site with:
$ cd my-test
$ hlx up

/cc @davidnuescheler

The message

You can verify the action with:
$ wsk action invoke -r --blocking local--pauldemo--dirty--html -p owner  -p repo  -p ref master -p path /index.md

should be in the same color as the hlx init "next step message"

it should be possible to install hlx without going through npm -g install hlx which has native compile dependencies; i.e.the developer should not be bothered installing a c++ compiler.

the application should be installed with all dependencies included, suited for the respective OS version.

macOS

• brew
• shell installer (?)

linux

• rpm, dpkg
• shell installer (?)

windows

• ?

until we can bundle the static files into the (web) package, they should be processed by hlx up and hlx build and be copied to the ${distDir}. default for the ${distDir} is .hlx/dist.

See better options mentioned here: #14 (comment)

with more and more options to configure the various commands, it might make sense to support reading the options and flags from a config file.

suggest:

use the helix-config.yaml and add the configuration options:

example

contentRepo: https://github.com/Adobe-Marketing-Cloud/reactor-user-docs

loglevel: info
build:
  - target: .hlx/build
  - files: src/*.htl
  - cache: true
  - minify: false

server:
  # ??? move this here?
  contentRepo: https://github.com/Adobe-Marketing-Cloud/reactor-user-docs
  port: 3000,
  browser: false
  
deploy:
  auto: false,
  apikey: ${WSK_AUTH}
  apihost: runtime.adobe.io
  namepsace: ${WSK_NAMESPACE}
  loghost: example.loggly.com
  logkey: ${HLX_LOGKEY}
  target: .hlx/build # maybe reuse build.target
  docker: nodejs8:latest
  default:
    flags: 'green'

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)

Disable with --no-open

It would be great to use a standardized logging concept withinh the console apps.
winston supports categories: https://github.com/winstonjs/winston/blob/master/README.md#working-with-multiple-loggers-in-winston and we could use this:

• each class/file acquires the logger via winston.loggers.get() (eg. winston.loggers.get('git-server')
• onInit of a module, it checks if the respective category is already present (winston.loggers.has()) and if not, configures it.
• maybe create a helix-winston-config module for harmonization.

I read about cheat.sh on the break today and thought we could build something similar.

‘hlx guide’ should show a step by step tutorial that helps you to get up and running. If you haven’t run ‘hlx init’ yet, it will be the default command.

If you do not add a dev dependency to adobe/parcel-plugin-htl in the "code" project, hlx build and hlx up does not compile the htl and pre.js files.

I think the hlx-cli should to bring whatever it needs and do not require the "code" project to have certain dev dependencies constraints.

+1 yes. dev deps only for testing

-1 I think it's better to make the dependencies explicit, so that you can add support for other templating languages simply by adding them as a dependency of your project instead of having us to adjust helix-cli for every new language.

adobe/project-helix#243 should take care of bootstrapping the project so that you don't forget about the dependency.

...so that you can add support for other templating languages simply by adding them as a dependency of your project instead of having us to adjust helix-cli for every new language.
true. but then, hlx up should probably complain if no parcel plugin is defined with a appropriate error message.

I agree.

Or even suggest to add it itself.

as mentioned in #53, helix should provide a static file handler that stores the files in a github repo.

• provide configuration option for GH (url, auth, branch)
• provide deployer that commits the static files to github
• provide fastly config for github access

Initially, the github repository should be the same as the code repository, using a detached branch named helix-static. this is a similar concept to github-pages.

• from deploy: get code location
• from yaml: get content location
• from yaml: get conditions

$ hlx init
Not enough non-option arguments: got 0, need at least 1

correct, but not helpful. Just show

hlx init <name> [dir]

Initialize the project structure

Positionals:
  name  Name of the project to initialize                    [string] [required]
  dir   Parent directory of new project                  [string] [default: "."]

Options:
  --version  Show version number                                       [boolean]
  --help     Show help                                                 [boolean]

For extending the openwhisk actions with additional scripts or content, it would be better to deploy a .zip package instead of the raw script.js.

this is required for #53

Run:

hlx init

Edit the helix-config.yaml file and define the contentRepo url

hlx build
hlx deploy

-> Error

(node:38934) UnhandledPromiseRejectionWarning: OpenWhiskError: PUT https://runtime.adobe.io/api/v1/namespaces/acapt/actions/--dirty--html?overwrite=true Returned HTTP 400 (Bad Request) --> "The name of the entity contains illegal characters."
    at Client.handleErrors (/Users/alex/.nvm/versions/node/v9.11.2/lib/node_modules/@adobe/helix-cli/node_modules/openwhisk/lib/client.js:157:11)
    at rp.catch.err (/Users/alex/.nvm/versions/node/v9.11.2/lib/node_modules/@adobe/helix-cli/node_modules/openwhisk/lib/client.js:117:38)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:182:7)
(node:38934) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:38934) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Reason is the missing git remote for the "code" (no git remote repo) which is used as to generate the action name.

cc @trieloff @tripodsan

As a first approach, the static files are just copied over to .hlx/dist. while this works for local development, it does not work for production. eventually the static files need to be served to the CDN.

similar to the approach in https://github.com/adobe/project-helix/pull/266, the static files could be made available via wsk action. however, I don't think that the wsk-action should load it again from git, because the codeload usually provides too much content.

The static resources could be bundled in the wsk action that delivers them. either in a generic static-server action contains all the resources needed to the project, or alongside the respective html.js action.

Alternatively, a gh-pages approach would be better instead of abusing wsk as a static file server. For each deployment, the static files are committed into a helix-static branch, and the ref of the current state is used in the strains.yaml to configure the static server.

how it works

having a separate static-server action is better, as the fundamental idea of just delivering static assets is easily applied to other mediums (S3, etc.)

1. the parcel-plugin-htl is enhanced so that it also processes the sub-assets referenced in the htl code adobe/parcel-plugin-htl#16
2. the plugin generates the .hlx/build/html.js and also the .hlx/dist/* variants of the referenced assets.
3. the hlx deploy deploys not only the html.js action, but also a static-server action that provides a simple server for the static files or commits the static files into helix-static.

@davidnuescheler commented on Aug 10, 2018, 4:04 PM UTC:

looking at...

[hlx] info:     __ __    ___
[hlx] info:    / // /__ / (_)_ __
[hlx] info:   / _  / -_) / /\ \ /
[hlx] info:  /_//_/\__/_/_//_\_\ v0.1
[hlx] info:
[hlx] info: Initialized helix-config with:
[hlx] info:  contentRepo: null
[hlx] info:      srcPath: /Users/tripod/codez/helix/foo/src
[hlx] info:     buildDir: /Users/tripod/codez/helix/foo/.hlx/build
:sparkles:  Built in 760ms.
:sparkles:  Copied static in 8ms.

[hlx] info: Launching local git server for development...
info: configuration successfully read: <internal>
info: [33274] HTTP: listening on port 59301
[hlx] info: Launching petridish server for development...
[hlx] info: Petridish server listening on port 3000.
[hlx] info: Open soupdemo at http://localhost:3000/index.html

makes me feel that there is a lot of somewhat superfluous information. this looks fine for debug mode, but i think we should reduce it to:

[hlx] info: Local Helix Dev Server up and running: http://localhost:3000/

...or similar.

also, we may remove the beautiful ascii art? unless someone is particularly attached to it...

This issue was moved by tripodsan from adobe/project-helix#275.

Similar when working with wsk, the hlx deploy command should recognize .wskprops and not just the environments.

as mentioned in #53, helix should provide a static file handler that stores the files as package in the component's function

• provide script that replaces the main.js in openwhisk that can deal with requests to static files.
• provide deployer that creates the deployment package
• provide fastly config for openwhisk handler

as mentioned in #53, helix should provide a static file handler that stores the files as package in the component's function.

This requires documentation and samples

Initialization of a new project, so that #5 doesn't happen anymore.

eg:

$ hlx foo

or

$ hlx up --foo-bar=123

do not produce errors.

The static files are only copied to the .hlx/dist folder during hlx build or at the start of hlx up.
Until parcel-bundler/parcel#1828 is fixed, the hlx up should watch and process them, too.

As we get more tests, let's see if we can run them in parallel to speed up CI

Performance testing of deployed site.

fix and test that

• HLX_AUTH
• HLX_APIHOST ?
• HLX_LOGKEY
• HLX_LOGHOST ?

act as defaults for the respective params.

@trieloff why don't we name it HLX_WSKAUTH and HLX_WSKAPIHOST and HLX_WSKNAMESPACE and/or support for .wskprops ?

We will have keys/auth for at least:

• OpenWhisk
• Loggly
• Fastly

So having it consistent as:

• HLX_WSK_AUTH + HLX_WSK_HOST, HLX_WSK_NAMESPACE
• HLX_LOGGLY_AUTH + HLX_LOGGLY_HOST
• HLX_FASTLY_AUTH + HLX_FASTLY_HOST

might be the best option.

suggest

--port, -p option

eg:

hlx up --port 4502

Quickly remove .hlx/cache and .hlx/build

• better control on when to build
• better output options
• coordinate with static file handling
• circumvent hanging workers-bug in parcel

• tag snapshots as next, not latest
• create git tags for snapshot releases
• document versioning in contributing.md

as mentioned in #53, helix should provide a static file handler that stores the files in Azure Blob Storage.

• provide configuration option for azure (auth, etc)
• provide deployer that uploads the static files to azure
• provide fastly config for Azure access

As explained in adobe/parcel-plugin-htl#22, the parcel plugin will only be responsible to create the template that renders the resource.

the build process will be responsible to setup the pipeline, wire the pre and wrap it up as openwhisk action. this will allow to:

• remove complexity and delivery domain logic from the parcel plugin
• be flexible about what function to generate (openwhisk, lambda, azure)
• turn the pre.js into a real pre function in the pipeline (nice to have)

$ hlx strain --fastly-namespace=3l2MjGcHgWw5NUJz7OKYH3
Unknown arguments: logglyHost, logglyAuth

fastly-namespace is set via environment variable.

as mentioned in #53, helix should provide a static file handler that stores the files in S3.

• provide configuration option for S3 (auth, etc)
• provide deployer that uploads the static files to S3
• provide fastly config for S3 access

as mentioned in #53, helix should provide a static file handler creates the static files dynamically in a openwhisk function by loading the respective code git-repository and providing a function that can deliver the files.

• provide script that acts as file server in openwhisk (see poc https://github.com/adobe/project-helix/pull/266)
• provide deployer that creates the deployment package and deploys the "server" to wsk
• provide fastly config for openwhisk handler

We should provide an easy way of rolling a deployment back to a previous state (as an emergency operation in case something goes wrong in production).

I could imagine generating a deployment ID and re-running the deployment for this particular version.

For clean deployments this should be relatively easy, as we can just restore the ref at the time of deployment. For --dirty deployments we might have to think of a workaround.

Once parcel-bundler/parcel#1690 is merged

once adobe/helix-simulator#5 is fixed, helix-cli should pass along the proper config

When developing templates, you want to be able to quickly validate if you are getting the required output.

Three places to run the test

1. --local loads your local .hlx/build scripts or petridish, runs them and validates the output
2. --runtime does the same, against the function deployed in OpenWhisk
3. --live makes an HTTP request to the deployed function through the CDN

How to specify input:

In tests/ create a file [<selector>_]?<extension>.[0-9]+.spec.json, [<selector>_]?<extension>.[0-9]+.spec.md, or [<selector>_]?<extension>.[0-9]+.spec.har that matches your selector_extension pair. For the default, you would have a html.0.spec.json. For the selector example, you'd have example_html.0.spec.json

The number before .spec allows the creation of multiple test files.

JSON Input

JSON can only be used for --local and --runtime. The entire JSON object will be used as the pipeline input.

JSON can be used in combination with Markdown.

Markdown Input

Markdown can only be used for --local and --runtime. It can be used in combination with JSON.

The content of the JSON document will be put into resource.body of the pipeline payload, so that the HTTP fetch step can be skipped, enabling offline testing.

HAR Input

If you create a .har (this is the HTTP Archive you can capture in your browser's dev tools), it will be used to make requests against the --live instance or against petridish.

How to specify output:

In tests/ create a file [<selector>_]?<extension>.[0-9]+.out.<extension>, e.g:

• html.0.out.html for default HTML
• json.0.out.json for default JSON
• example_html.0.out.html for HTML with the example selector

hlx init should also add a css file and maybe a fav.ico so that users see how static files are delivered.

suggest

dist/fav.ico
dist/main.css

strains.yaml ends up in the .hlx folder. It is generated by hlx, but I would not expect to edit files in .hlx folder. We never edit files in the .git folder…

Build just keeps running, as if it was watching.