https://github.com/inventsable/cep-self-signing-panel
How to create a panel that stages and signs itself with a `npm run sign` command
https://github.com/inventsable/cep-self-signing-panel
Last synced: about 1 year ago
JSON representation
How to create a panel that stages and signs itself with a `npm run sign` command
- Host: GitHub
- URL: https://github.com/inventsable/cep-self-signing-panel
- Owner: Inventsable
- Created: 2019-06-22T18:30:33.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2021-10-05T23:06:39.000Z (over 4 years ago)
- Last Synced: 2025-05-07T22:12:50.482Z (about 1 year ago)
- Language: JavaScript
- Size: 5.64 MB
- Stars: 6
- Watchers: 1
- Forks: 2
- Open Issues: 15
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# CEP Self-Signing Panel
## This panel can stage, sign and certify itself in a single command:
> 
## [> Skip to Usage](#usage)
## Adding this functionality to your own panel (skip to #5 if a template from cep-vue-cli made after 6/23/19)
### 1. Copy and paste the following into your `package.json` under `devDependencies`:
```json
"boxen": "^4.1.0",
"chalk": "^2.4.2",
"core-js": "^2.6.5",
"fs-extra": "^8.0.1",
"inquirer": "^6.4.1",
"make-runnable": "^1.3.6",
"ora": "^3.4.0",
"shelljs": "^0.8.3",
```
### 2. We create custom tasks by pasting this into the `scripts` section of your `package.json`:
```json
"sign": "node ./src/utils/dev/npmCommands.js sign",
"switch": "node ./src/utils/dev/npmCommands.js switch",
"update": "node ./src/utils/dev/npmCommands.js update",
"register": "node ./src/utils/dev/npmCommands.js register",
"help": "node ./src/utils/dev/npmCommands.js help"
```
This creates a command named `sign`, which will be used as `npm run sign`. It uses [make-runnable](https://github.com/super-cache-money/make-runnable) to allow a `node [path-to-file] [name-of-function] [parameters-to-pass]` syntax, so the above `node ./src/utils/dev/npmCommands.js sign` is pointing to a function named `sign()` (with no parameters) inside the `npmCommands.js` file. Same for others like `switch` and `update`!
> You can see the above in action within [this repo's own package.json](https://github.com/Inventsable/CEP-Self-Signing-Panel/blob/master/package.json)
### 3. Copy [the ./src/utils/dev folder from this repo](https://github.com/Inventsable/CEP-Self-Signing-Panel/tree/master/src/utils/dev) to the same path. Path must be exact as it generates config files after first use.
### 4. npm install and verify
```bash
# Now re-run npm install
npm install
# Now try your new tasks! Starting with 'help' will give a full outline:
npm run help
```
### 5. You must have [ZXPSignCmd.exe](https://github.com/Adobe-CEP/CEP-Resources/tree/master/ZXPSignCMD/4.0.7) within the parent folder of your extension
If you're currently developing a panel whose path is `.../appData/Roaming/Adobe/CEP/extensions/myPanel`, ZXPSignCmd.exe must be in `.../appData/Roaming/Adobe/CEP/extensions`.
## What do they do?
### `npm run help` will:
- Prompt a full list of commands of the panel including the ones below
### `npm run sign` will:
- Duplicate and "stage" an extension folder to a temporary location, removing any hidden files or folders to ensure the certificate doesn't silently fail
- Generate a temporary certificate
- Sign the duplicate with the certificate
- Check the validation of the signed duplicate
- Place the resulting `[name][version].zxp` into `./archive` of your current panel (and create this folder if it doesn't already exist). If `[name][version].zxp` already exists, overwrite it
- Delete the duplicate directory
### `npm run switch` will:
> 🚩 This command only works if the panel was generated by [cep-vue-cli](https://github.com/Inventsable/generator-cep-vue-cli)
- Report whether the manifest is currently prepped for `PRODUCTION` or `DEVELOPER` context.
- Prompt the user if they'd like to switch contexts
- If switching contexts, automatically adjusts `manifest.xml` for you (no need to manually open it and switch every time)
- Prompt with contextual information about the next steps once the confirmation is made
### `npm run update` will:
- Report the current version of the panel
- Prompt the user to update the MAJOR, MINOR, or MICRO tier
- Auto-suggest the update as the next sequential number but allow any number to be entered
- Rewrite the version number within `manifest.xml` and `package.json` with the updated semantic version
### `npm run register` will:
- Report the current string of text to use for `npm run sign` certification
- Prompt the user for COUNTRY, STATE/LOCALE, ORGANIZATION, and COMMON NAME
- Write a new file (or overwrite previous) containing country, locale, organization and user
## Usage
When you first have created the template or need to start coding, you need `npm run serve` to launch the dev server and see your code reflect in the panel. If you want to build and sign an extension, then at any time you do so by running:
- `npm run build` - This builds/compiles/gulps everything to the ./dist directory
- `npm run switch` - This changes your manifest.xml file to point to the newly created ./dist/index.html compiled in the previous step. **Without this step, the ZXP will be pointing to a localhost which doesn't exist**
- `npm run sign` - This stages, signs, and certifies the panel to create a deliverable ready for any one's use. **Note that if you want the certification info to be correct**, you must run `npm run register` at least once to fill out your own data (otherwise dummy data is used).
To continue development:
- `npm run switch` - Change the manifest.xml back to the localhost for hot reloading
- `npm run update` **[OPTIONAL]** - To avoid losing or overwriting previous code, it's a good idea to update the version after every `npm run sign`. This allows us to easily keep track of deliverables and stages, and hand off guaranteed deliverables without mixing them up.
- `npm run serve` - Restart the development server and continue coding
A one-step or odd number shift (`developer` > `production` or vice versa) requires you restart the host application. A two-step or even number shift (`developer` > `production` > `developer`) requires only that you refresh the panel. This is because `manifest.xml` only reads once at the host app's launch, so switching it's entry point to change between `production` and `developer` will not be detected by the host app.