Configuring workflows

[SamVerschueren]

So, a couple of weeks back I thought we could make much more powerfull workflows if there was a way to configure them individually per user.

For instance, if someone creates a git workflow, the user installing that workflow should be able to put an API key somewhere. It's very dirty if he needs to change the workflow in that visual workflow editor and put the API key somewhere.

I have a couple of ideas for this, not sure if all that easy to do.

Configure script

We could allow a user to create a configure.js script which could use Inquirer.js or something to ask questions to the user. In the git workflow example for instance, either we create a new activation keyword, for instance configure-git which opens the terminal and executes configure.js. Or git configure for instance.

The name of that script could be set via package.json

{
  "name": "alfred-git",
  "alfy": {
    "configure": "configure.js"
  }
}

Configure questions

A second approach would be easier to add for the user. This would allow someone to define the questions in package.json and will store them in the config of the workflow. This way, in your workflow, you could just grab them from the config.

{
  "name": "alfred-git",
  "alfy": {
    "configure": {
      "api_key": {
        "type": "input",
        "message": "GitHub API key?"
      },
      "foo": {
        "type": "list",
        "message": "Some list here?",
        "choices": ["foo", "bar"]
      }
    }
  }
}

---

The first option offers the most flexibility in terms of the package you use to ask your questions (although 2 would offer more consistency).

The second one would definitely be easier for the developer, though less flexible. This would also mean every workflow is packaged with Inquirer.js, not sure how "heavy" it is. Although, it might be an idea to extract this in a separate package called alfy-configure and keep this the core. Something like alfy-test.

---

Note: This issue has a bounty, so it's expected that you are an experienced programmer and that you give it your best effort if you intend to tackle this. Don't forget, if applicable, to add tests, docs (double-check for typos), and update TypeScript definitions. And don't be sloppy. Review your own diff multiple times and try to find ways to improve and simplify your code. Instead of asking too many questions, present solutions. The point of an issue bounty is to reduce my workload, not give me more. Include a 🦄 in your PR description to indicate that you've read this. Thanks for helping out 🙌 - @sindresorhus

---

IssueHunt Summary

samverschueren has been rewarded.

Backers (Total: $100.00)

• issuehunt ($100.00)

Submitted pull Requests

• #113 Add support for user-configurable workflows

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[SamVerschueren]

Tried to play with it. I can launch the terminal from an Alfred workflow but the working directory is just set to $HOME. This means that we can't use run-node config.js or something like that. So to make a workaround for this, I had to configure config.js as bin of my workflow and then you could do config-ng2 in your terminal. Not sure about the entire process yet. Have to discover more possibilities first.

[SamVerschueren]

Maybe the idea of exposing a binary as part of your workflow (in case you want configuration) isn't that hacky after all.

1. It doesn't bloat the Alfred app with config worklows (e.g. ng2 and config-ng2 for instance)
2. It let's the user configure the workflow easily from the command line
3. The workflow developer can always choose to launch the command from within the workflow (keyword -> execute command)

Another possibility is to let the developer pick a keyword like config and then intercept the input of the user. If the user enters ng2 config, it will start the terminal with the config command. But I guess just exposing config-ng2 as binary command and let the users configure it through the terminal might already be a huge improvement.

[SamVerschueren]

Oh, this just popped in my mind and might actually be the best approach.

The user provides the app with config.json if they want custom config. For instance when you want to create a git search workflow, it could look like this (possibility to add comments).

/**
 * alfred-git config file
 */
{
    // GitHub API Key
    "apiKey": ""
}

alfy-init copies that file over to the config directory on the filesystem to make sure it doesn't get lost when upgrading. If the config file already exists, it will merge the files in case new ones where added.

When installing the workflow, it will call alfy-init and it will then open that file with the filesystem text editor.

Somehow (not sure how yet), with a command (either Alfred or cli), it should be possible to open the config file again if you want to make changes.

This doesn't require some tools like Inquirer.js but gives flexibility to the developer creating the workflow.

[sindresorhus]

I like the above solution of just using a simple config file.

Can use strip-json-comments to allow comment in the JSON.

Somehow (not sure how yet), with a command (either Alfred or cli), it should be possible to open the config file again if you want to make changes.

Probably easiest to just expose a CLI binary.
For example: $ alfred-emoj config (Could maybe have other commands in the future)

[SamVerschueren]

Looking into this. I guess it will be difficult to keep the comments in the config file. The reason is that I want to perform a merge if the workflow gets updated. Let me clarify with an example.

This is the config.json file for alfred-git@1.0.0

/**
 * alfred-git config file
 */
{
    // GitHub API Key
    "apiKey": "abcd"
}

This gets copied over to the config directory and the user fills in the API key like this.

/**
 * alfred-git config file
 */
{
    // GitHub API Key
    "apiKey": "abcd"
}

The workflow gets updated, and a new config property was added.

/**
 * alfred-git config file
 */
{
    // GitHub API Key
    "apiKey": "",

    // GitHub username
   "username": ""
}

I can't just overwrite the config file in the config directory as the user already set the API key. This means I will have to merge both config files and write the result of that merge. (Merging also means removing properties that where removed with the updated workflow). So after the merge, the result should be this.

/**
 * alfred-git config file
 */
{
    // GitHub API Key
    "apiKey": "abcd",

    // GitHub username
   "username": ""
}

But I believe it's quite hard to parse the JSON file without removing the comments (strip-json-comments). And when I remove them, I can't put them back later on in the process. Unless I parse everything AST wise and update the notes like that. I can always have a look to projects like json-parser though.

The question we could ask is, should we preserve comments? I believe we do because it could clarify the settings. Not sure how we can accomplish this though.

[SamVerschueren]

I thought about this for a while and if we just use a flattened object, we might get away with simple regex expressions to do the merge. VS Code also has a flattened object and supports comments.

{
  "editor.insertSpaces": false,
  "editor.scrollBeyondLastLine": false,
  "editor.formatOnType": true,
  "editor.renderIndentGuides": true,
  "editor.fontFamily": "Fira Code",
  "editor.fontLigatures": true,
  "editor.acceptSuggestionOnEnter": false
}

Or we could just start without support for comments and use something like Object.assign() or deep-assign to do the merge. Although if we would support nested objects, this might prevent us from implementing the above in the future.

[sindresorhus]

Maybe we could use this: https://github.com/hjson/hjson-js#modify--keep-comments ?

[SamVerschueren]

Sweet! Will look into that. Already started working on something so I hope I could do a PR this week. Would make possibilities with Alfred endless...

[SamVerschueren]

I'm creating a separate package that handles all this stuff. Feedback for a name of the package?

• alfy-config
• alfred-config
• alfy-workflow-config
• alfred-workflow-config

The alfred prefix is more in line with what we have today...

• alfred-link
• alfred-notifier

[shockwavemoto]

We could allow a user to create a configure.js script which could use Inquirer.js or something to ask questions to the user. In the git or we could just start without support for comments and use something like Object.assign() or deep-assign to do the merge. Although if we would support nested objects, this might prevent us from implementing the above in the future.
Or we can support the other idea also
🛩️ 🛩️ 🔸

[issuehunt-oss]

@issuehunt has funded $80.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[issuehunt-oss]

@issuehunt has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[SamVerschueren]

I'm trying to pick this one up again :). But give me some time to get back at it :).

[sindresorhus]

If anyone wants to work on this, see the initial attempt and feedback in #113.

[issuehunt-oss]

@sindresorhus has rewarded $90.00 to @samverschueren. See it on IssueHunt

• 💰 Total deposit: $100.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $10.00