Using Pro

So you've decided to support TaskBotJS and ensure it's future by signing up for TaskBotJS Pro or Enterprise. That's awesome, and thank you either for pulling the trigger already or being interested in doing so. Here's what you'll need to know.

Purchasing Access

Access to TaskBotJS Pro or Enterprise can be purchased through a Stripe subscription; Pro is $895 per year.

Once you've purchased a year's license, you'll be provisioned with a GitLab account on the internal project tracker, where you'll be able to see the Git history of Pro or Enterprise respectively. You'll also be able to file issues related specifically to Pro concerns there. We use GitLab's confidential issues feature as our primary support channel; by creating a confidential issue and marking it as a request for support, you'll immediately get my attention. This account is per licensee; your company gets a single account for every concurrent subscription to TaskBotJS, so be sure to have a good way to save its credentials.

Once you have access to GitLab, you will be able to create a Personal Access Token. This GitLab API token is important because it allows access to the private NPM registry, where @taskbotjs-pro/client and friends all live. This GitLab token will be the authentication password given to the NPM registry, as discussed in the next section.

Using TaskBotJS Pro In Your Workflow

Private NPM registries are a new thing to a lot of folks, so we'll briefly go over how to access our packages.

First: it is a bad idea to reply on my private NPM registry for everyday work. That's not to say that I won't maintain it or that you're likely to have it go down on you, but having every customer's developers regularly pummel the registry server isn't great for anyone. On top of that, while devops is my day job, everybody does make mistakes and that's not just me--that's NPM-the-company just as well. (Remember the left-pad disaster?) Instead, your company really should have a private NPM mirror. I run Verdaccio, and in fact the software serving the TaskBotJS Pro registry is exactly that, but you can also use Gemfury or a similar third party to act as an intermediated cache between you and the scary outside world of network outages and pulled packages. It'll also make breaking your own software into composable chunks a good bit easier when you don't have to pull commits from Git or whatever. It's just a better choice all around.

But, for a second, let's assume you aren't using a private NPM cache and you're going to read directly from the TaskBotJS registry, which lives at npm.edboxes.com.

npm (the binary; yarn too) have the concept of scoped packages. By using an .npmrc file, we can specify a registry specifically for a given scope--in our case, @taskbotjs-pro or @taskbotjs-ent. These files can live in your home directory or in the project directory, with more specific ones overriding less specific ones--pretty standard stuff.

Generally speaking, teams I've worked with have had good success with storing these in projects themselves; a new developer comes onboard, pulls the project, and everything works as expected. It maps pretty similarly to how one would use sources in a Ruby Gemfile. Your .npmrc file shold look something like this:

registry=https://registry.npmjs.org/

@taskbotjs-pro:registry=https://npm.edboxes.com/
@taskbotjs-ent:registry=https://npm.edboxes.com/
//npm.edboxes.com/:always-auth=true
//npm.edboxes.com/:username=GITLAB_USERNAME
//npm.edboxes.com/:_password=GITLAB_PERSONAL_ACCESS_TOKEN
//npm.edboxes.com/:email=foo@example.com

(Please note that the trailing slash is required, otherwise yarn might have a sad.)

GITLAB_PERSONAL_ACCESS_TOKEN can be acquired from logging into GitLab and generating an access token. (Ordinarily it's a little fraught to store project credentials in a git repo, but these are shared development credentials; it's somewhat unavoidable unless you have a significantly more elaborate development structure than most of my clients!)

When in a repository with this .npmrc file you can log in on a user level by going npm login --always-auth --registry https://edboxes.com, and npm will pre-fill your authentication data from the project .npmrc file. It'll then work transparently, fetching @taskbot-pro or @taskbot-ent-scoped packages from me and everything else from NPM.

The other alternative method of deploying is to use an _authToken, where you log into one system with npm login --registry https://edboxes.com and copy the contents of ~/.npmrc into the project directory. This token is safe to use on any machine, but can be expired by any developer by logging out of NPM on their machines--so it's a little less safe.

Ultimately, though, your best option is to use your own proxy, centralize access to TaskBotJS, and go from there.

Cancellation and Nonpayment

Should you wish to cancel TaskBotJS Pro or Enterprise, you'll still retain access to the GitLab server and to the private NPM registry until the end of your current year's subscription.

If your subscription is being auto-renewed and payment fails for some reason, I'll reach out to the e-mail address on file. I'm not here to throw a wrench into your development workflow, and so I won't just pull the plug on your access, but you can expect me to rescind access if I haven't heard from you within 30 days after the first attempted subscription renewal.