xtn

npm walk

xtn is the command namespace

xtn --version version of the xtn-cli service

AUTHENTICATION xtn login interactive login to create a token in the global ~/.xtn space

xtn logout

LINKING EXTENSIONS

xtn link binds the current working directory with a .xtn file mapping the id known to xtn. Allows a search of known extensions in your account. Or it could be that we give them a git clone like step to do this.

PUBLISHING xtn publish uploads and lets service run deploy/publish scripts based on service configured settings

xtn publish {aliasName} does publish on one of the linked xtn extensions. Allowing for a single codebase to be linked to multiple extensions (with their own configuration) like staging then production.

xtn publish --status {aliasName} shows the publish status of the last 3 attempts with time ago stamps (perhaps similar to now ls layout)

VIEWING PUBLISHED VERSIONS xtn {download|fetch} {version|id|'latest'} let's a user download a specific version of the extension that xtn knows about

BUILDING LOCALLY xtn build --{platform-name} {directory} does the build step for the platform type and puts it into the specified directory

HOSTING xtn host --description="New Feature X" {aliasName} does a publish that we will host and make available for xtn linked users. it does not send the extension to the stores. This is only available for hostable extension types like web extensions.

--- possible process flows ---

onboarding

• upload extensions to webstore manually first (perhaps we have a step through to help or an extension to guide them)
• create xtn account
• link any accounts needed (e.g. Google for webstore)
• add extension to account by
  • naming extension (only requirement other than )
  • prompt to specify store id or find in store - where we add the store identifier automatically
  • note: adding to the store as a first step is required for FF and probably chrome so that you can sign any agreements and pay any fees
• Updating metadata can be done manually via uploads or imported from codebase

deploying

• cli will upload project and run deploy
• optionally, users can upload project (similar to commits) periodically and have a deploy button on ui to deploy
• status updates
• CI can be enabled by having a CI user or the team admin having access to a CI secret that can request a deploy token
• ability to upload version changes by platform, separately. Specifically if something goes wrong with only ff, a user should be able to deploy a patch, only to ff.

deploy helpers

• allow a {platform}.manifest.json to have a special deploy-time process of merging those contents with manifest.json
  • in future, if we get to allowing build steps on our side (we assume it's built minus manifest.json merging atm) we can do this {platform}.{filetype} overriding before running build scripts. But devs can do that now if they wanted to in their own fashion at build time

tokens

• users get 5 tokens to be used on unique machines and can revoke tokens from UI
• tokens are long lived

notifications

• setup accounts and what should be sent to where, when.

teams

• allow folks to have access to controls and work from the same
  • Google already has teams. I wonder if we should have one master google account that has ability to deploy and not worry about team access. Also makes it cheaper for team to do this work so that everyone who wants to deploy needs to have access.
• roles needed. Admin, can upload, can deploy, etc.

developer tools

• ability to quickly start a new extension
• wrappers around methods that are manifest.json aware - allowing helpful warnings if you try to use functions without a permission enabled

analytics

• get better information on install rate, uninstalls, opens, etc.
• engagement scores
• push information via notifications to any configured services

version footprint info

• answer these questions
  • what version is currently publicly accessible
    • notify when changes
  • what where the rating changes by versions

ratings & reviews

• track and notify on changes

notifications tooling

• allow owners to trigger notifications remotely from the service to their users
• along with tracking of pattern usage of extension (last opened, n times interacting)

actionable metrics