@hubspot/app-functions-dev-server
v0.10.2
Published
A tool for testing HubSpot private app functions locally
Maintainers
Keywords
Readme
Overview
Serverless functions provide a way for private apps to run server-side code on HubSpot's infrastructure, typically to interact with HubSpot or third-party APIs on behalf of the app's React frontend that runs in a user's browser. Serverless functions for private apps are also called app functions.
The app functions dev server allows for app functions to run locally on a developer's machine instead of on HubSpot. This is useful for quick iterative development, epsecially when also running the React extension in local dev mode. However, there may differences between local and production execution.
Pre-requisites
- There is a project that contains the private app, which contains the app functions.
- The HubSpot CLI has been initialized for the project and a target account.
- The developer has a valid Personal Access Key (PAK) for the account. The PAK must contain at least the same scopes as those specified for the private app in the
app.jsonfile. - If an app function requires a secret, the developer must supply a value for the secret using a
.envfile in theapp.functionsdirectory. This applies to the PRIVATE_APP_ACCESS_TOKEN, too. See dotenv for more information about .env files and their variants.
CAUTION: Add the pattern ".env*" to your
.gitignorefile so that secrets do not get committed to a repository by mistake. Hidden files are automatically ignored when using the CLIuploadandwatchcommands.
Usage
app-functions-dev-server runs as part of the ui-extensions-dev-server. To run and develop this codebase, follow the contribution guidelines in the dev server repository.
Deploying Changes
Because this package is a dependency of other tools, rather than something used directly, there are a few steps involved in deploying changes. First, the package is released to NPM. Then, the dependency version is bumped in the consuming ui-extensions-dev-server package.
Releasing the NPM Packages
[!NOTE] This guide is intended for
@HubSpot/ui-extensibilityengineers, who've already logged into public npm viabend yarn npm:loginand have publishing credentials stored locally in~/.npmrc.public_publish. If you don't have that file locally, or aren't sure what this means, reach out in #ui-extensibility.When ready to publish your changes, the process is similar to how we publish other UIE assets, but
changesetsis refreshingly simple when compared tolerna.
The Changesets CLI calculates the appropriate version based on all the changes queued up for release in the .changeset/ directory, and prepares your packages for release. This "versioning resolution" process is entirely automated and doesn’t require you to manually intervene.
- Ask your teammates to hold off on merging until you're done with this process\
- Check the
.changesetdirectory to see if there is a.mdfile for this release. If not, generate one withyarn changeset. Open a PR with these changes before continuing on. - Make sure you've got all git tags pulled down locally, via
git pull --tags -f - Run
npm run changeset:versionto generate the new version number, and update thepackage.jsonaccordingly. This delegates to thenpx changeset versioncommand with your npm credentials properly applied - Run
npm run changeset:publishto ship your updates to the public registry! This delegates to thenpx changeset publishunder the hood - Check the @hubspot/app-functions-dev-server package on npmjs.com to see the updated contents (or use the CLI to inspect it a la
npm show @hubspot/app-functions-dev-server) and verify you can install and use the new version - Run
git push --tagsto push the generated tags to the remote repo - Open up a PR with the changes from your release.
Updating Package Consumers
Releasing the NPM package isn't enough. You also need to update the consumers of the package before the change is considered "fully released". Some changes require just a CLI bump, others require just an Artifactor bump, and some will need both.
If the changes impact the CLI, put in a PR in their repo to bump the version.
If the changes impact the remote build, put in a PR in Artifactor and use our docs to help test and release the version bump.
