Amber: [CLI] Amber Watch - Configurable

[drujensen]

Description

This request is to change the amber watch command to be configurable. This will remove the dependency on npm and allow for other services to be added if wanted.

The configuration will be stored in the .amber.yml file:

type: app
database: sqlite
language: slang
model: granite
watch:
  server:
    files: ["src/**/*.cr", "src/**/*.ecr"]
    command: shards build
  client:
    files: "public/**/*"
    command: ["yarn install", "yarn run watch"]
  jobs:
    files: "src/jobs/*"
    command: crystal run src/sidekiq.cr

[faustinoaq]

Interesting, maybe we can use https://github.com/f/guardian to solve this issue, WDYT?

[elorest]

Or since we've incorporated sentry we could just modify it to do what we need.

[eliasjpr]

I agree with @elorest less dependencies to manage

[faustinoaq]

I think we should add this feature to config/enviroments/development.yml because amber watch is only useful in development phase so would be good to have this kind of settings in this place, WDYT?

Something like:

secret_key_base: eV7pl_XuPgROPHGmuy0TSMC2yQ3OCInvRg4pxmj5nUA
port: 3000
name: forum

logging:
  severity: debug
  colorize: true
  filter:
    - password
    - confirm_password
  skip:
    -
  context:
    - request
    - session
    - headers
    - cookies
    - params

watch:
  server:
    files:
      - "src/**/*.cr"
      - "src/**/*.ecr"
    command: shards build
  client:
    files: "public/**/*"
    command:
      - "yarn install"
      - "yarn run watch"
  db:
    files: "db/**/*"
    command: amber db migrate
  jobs:
    files: "src/jobs/*"
    command: crystal run src/sidekiq.cr

host: 0.0.0.0
port_reuse: true
process_count: 1
# ssl_key_file:
# ssl_cert_file:
redis_url: "redis://localhost:6379"
database_url: sqlite3:./db/forum_development.db

session:
  key: amber.session
  store: signed_cookie
  expires: 0

secrets:
  description: Store your development secrets credentials and settings here.

BTW, we should resturcture development.yml as well, I think port should be beside to host, not too separated.

[eliasjpr]

This type of configuration if for the CLI so it should live in .amber.yml. The environment settings are for App specific settings

[eliasjpr]

@faustinoaq I am not sure we would like to have this, since it would mean that if you have amber w running and generate a new migration the migration will run immediately. WDYT?

db:
    files: "db/**/*"
    command: amber db migrate

Also make use of .amber.yml not the {enviroment}.yml

[faustinoaq]

Also make use of .amber.yml not the {enviroment}.yml

Sure, no problem :+1:

I am not sure we would like to have this, since it would mean that if you have amber w running and generate a new migration the migration will run immediately. WDYT?

I think you and the amber community would like it :wink:

The way I'm implementing this, allow you to add optional "watch" entries. Each "watch" entry is composed by files and commands, the "basic" (predefined and required) entries are:

1. server: the most important,, this allow to reload amber on changes and print compile error to the browser (is a new feature :tada: )
2. client: watch all files inside public directory, and send a reload signal to the browser using websockets
3. js: "compiles" or copy the javascript files to the public bundle
4. css: "compiles" or copy the styesheets files and images (optional) to the public bundle

type: app
database: pg
language: slang
model: granite
watch:
  server:
    files:
      - "src/**/*.cr"
      - "src/**/*.slang"
      - "config/**/*.cr"
    commands:
      - crystal build -o bin/app01 src/app01.cr -p --no-color
      - bin/app01
  client:
    files:
      - "public/**/*"
    commands:
      - "echo 'XX:XX:XX Watcher    | Watching public files'"
  js:
    files:
      - "src/assets/javascripts/*.js"
    commands:
      - "cat src/assets/javascripts/*.js > public/dist/main.bundle.js"
      - "cp lib/amber/assets/js/amber.min.js public/dist/amber.min.js"
# ^^^ Using cat and cp to avoid using tools like NPM, can be used in a recipe, though
# You can execute the command you want (webpack, parcel, rollup)
# But without --watch mode because amber is already watching for changes
# If you want to use an external watcher then you need an empty array of files
# (see rule 2)
  css:
    files:
      - "src/assets/stylesheets/*.css"
    commands:
      - "cat src/assets/stylesheets/*.css > public/dist/main.bundle.css"
      - "cp -r src/assets/images public/"
 # ^^^ Same happens here, if you have sass/lless/stylus/postcss
 # available in your pc you run them here :)

Finally you can add custom commands like db, jobs, etc:

the rules are: (until now)

1. Every "watch" entry must have a "files" entry, that can be empty like this

  watch-shards:
     files:
        -
      commands:
        - "webpack --watch'"
        # ^^^ Entries with empty files array are executed just at beginning,
        # useful for external watcher commands

1. if files is not empty then the commands are executed every time some change is detected for files in this watch entry

2. Every "watch" entry must have a commands entry, with one or more commands (except in basic client entry, you can use empty array here), that are triggered and executed sequentially when files are changed, although if "files" is empty then rule 2 is applied

# ...
watch:
  # ...
  watch-entry:
     files:
        - "shard.yml"
      commands:
        - "echo 'XX:XX:XX Watcher    | shard.yml has been updated'"
   # ... more commands

[faustinoaq]

Right now I'm resolving a WebSocket bug that is blocking client reload (a little issue, already being solved)

All features explained in the comment above are already implemented in my local repo :wink:

[faustinoaq]

Just to point out, the new watcher can allow us to watch task managers like mosquito by @robacarp

Currently:

Take note that no code reloading for jobs exists, so when a job is changed you must restart the worker.

In the Future:

After this issue is solved, code reloading for jobs will be possible :tada:

type: app
database: pg
language: slang
model: granite
watch:
  server: # required: the first command for this task is blocking
    files:
      - "src/**/*.cr"
      - "src/**/*.slang
      - "config/**/*.cr"
    commands:
      - "crystal build -o bin/example src/example.cr -p --no-color"
      - "bin/example"

  client: # required: these files changes trigger browser reloading
    files:
      - "public/**/*"
    commands: []

  jobs:
    files:
      - "jobs/*.cr"
    commands:
      - "crystal run jobs/worker.cr"  # Task made with mosquito

[robacarp]

@faustinoaq that’s why I’m excited for this! I’m currently running mosquito in a separate terminal and manually restarting it.