@enfocussw/switch-scripting-context 25.11.0-beta.13 → 25.11.0-beta.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -0
- package/README.md +36 -35
- package/docs/switch-api/api-entry-points.md +10 -0
- package/docs/switch-api/api-project-planning.md +100 -0
- package/docs/switch-scripting.md +5 -0
- package/package.json +7 -4
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,24 @@ All notable changes to this package are documented here. Format follows
|
|
|
5
5
|
|
|
6
6
|
## [Unreleased]
|
|
7
7
|
|
|
8
|
+
## [25.11.0-beta.14] - 2026-09-09
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
- `switch-scripting.md` now tells agents to grep `docs/switch-api/` for `known issue`, `gotcha`,
|
|
12
|
+
`quirk`, `caveat` to find documented pitfalls before writing code in an area.
|
|
13
|
+
- `api-entry-points.md` documents that a flow restart replays every queued job through `jobArrived`
|
|
14
|
+
again, even one whose processing was deferred to `timerFired`. A script relying on that pattern
|
|
15
|
+
must recognize an already-registered job and return quickly, or a large backlog is slow to clear.
|
|
16
|
+
- `api-project-planning.md`, a pre-scaffolding checklist for new scripts and apps: Script vs App,
|
|
17
|
+
job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm
|
|
18
|
+
dependency feasibility, and Appstore competition risk. Loaded before any files are scaffolded.
|
|
19
|
+
|
|
20
|
+
### Changed
|
|
21
|
+
- `README.md` no longer uses dashes as punctuation. Wording is unchanged otherwise.
|
|
22
|
+
- The published README now links to the changelog on jsdelivr, pinned to the version being
|
|
23
|
+
installed. Relative links were rewritten by npm to the private repo, so they were dead for
|
|
24
|
+
consumers. `prepack` swaps them in and `postpack` swaps them back.
|
|
25
|
+
|
|
8
26
|
## [25.11.0-beta.13] - 2026-09-09
|
|
9
27
|
|
|
10
28
|
### Fixed
|
package/README.md
CHANGED
|
@@ -4,7 +4,7 @@ AI coding assistant context for [Enfocus Switch](https://www.enfocus.com/en/swit
|
|
|
4
4
|
|
|
5
5
|
Installs curated API reference docs and generates config files for 8 AI coding agents (Claude Code, GitHub Copilot, Cursor, Codex CLI/OpenCode, Gemini CLI, Windsurf, Zed, and Cline) so AI assistants understand the Switch scripting API out of the box.
|
|
6
6
|
|
|
7
|
-
See [CHANGELOG.md](CHANGELOG.md) (also included in this package) for what's changed between versions.
|
|
7
|
+
See [CHANGELOG.md](https://cdn.jsdelivr.net/npm/@enfocussw/switch-scripting-context@25.11.0-beta.14/CHANGELOG.md) (also included in this package) for what's changed between versions.
|
|
8
8
|
|
|
9
9
|
## Usage
|
|
10
10
|
|
|
@@ -34,13 +34,13 @@ The package version tracks the Switch release its docs describe:
|
|
|
34
34
|
└────── Switch version (25.11)
|
|
35
35
|
```
|
|
36
36
|
|
|
37
|
-
- `25.11.x
|
|
37
|
+
- `25.11.x`: every release of this package documenting **Switch 25.11**. Patch increments are doc updates, fixes, and new features of the CLI itself.
|
|
38
38
|
- The next Switch release moves the first two numbers (e.g. Switch 27.07 → `27.7.0`). Note that semver forbids leading zeros, so `27.07` is published as `27.7`.
|
|
39
39
|
- **Pin with `~`, not `^`.** `~25.11.0` stays on Switch 25.11; `^25.11.0` would happily install `25.12.0`, which targets a different Switch release.
|
|
40
40
|
|
|
41
41
|
### Prereleases
|
|
42
42
|
|
|
43
|
-
Beta builds append a prerelease suffix
|
|
43
|
+
Beta builds append a prerelease suffix, for example `25.11.0-beta.1`. These sort *below* `25.11.0`,
|
|
44
44
|
so the beta line precedes GA and leaves `25.11.0` free for the first published release.
|
|
45
45
|
|
|
46
46
|
## What it does
|
|
@@ -53,9 +53,9 @@ so the beta line precedes GA and leaves `25.11.0` free for the first published r
|
|
|
53
53
|
|
|
54
54
|
| Tool | File | How context is loaded |
|
|
55
55
|
|---|---|---|
|
|
56
|
-
| Claude Code / ClawCode | `CLAUDE.md` | `@switch-docs/switch-scripting.md` import
|
|
56
|
+
| Claude Code / ClawCode | `CLAUDE.md` | `@switch-docs/switch-scripting.md` import; hub file routes to specific API docs on demand |
|
|
57
57
|
| GitHub Copilot | `.github/copilot-instructions.md` | `#file:` reference to hub |
|
|
58
|
-
| GitHub Copilot (scoped) | `.github/instructions/switch-scripting.instructions.md` | `applyTo: "**/*.ts"
|
|
58
|
+
| GitHub Copilot (scoped) | `.github/instructions/switch-scripting.instructions.md` | `applyTo: "**/*.ts"`; auto-attaches to every TypeScript file edit |
|
|
59
59
|
| Cursor | `.cursor/rules/switch-scripting.mdc` | Inline key rules + full API file path list |
|
|
60
60
|
| Codex CLI / OpenCode | `AGENTS.md` | Inline key rules + full API file path list |
|
|
61
61
|
| Gemini CLI | `GEMINI.md` | `@switch-docs/switch-scripting.md` import |
|
|
@@ -63,28 +63,28 @@ so the beta line precedes GA and leaves `25.11.0` free for the first published r
|
|
|
63
63
|
| Zed | `.rules` | Inline key rules + full API file path list |
|
|
64
64
|
| Cline | `.clinerules` | Inline key rules + full API file path list |
|
|
65
65
|
|
|
66
|
-
All files use `<!-- switch-scripting-context begin -->` / `<!-- switch-scripting-context end -->` markers. Re-running `init` replaces only the Switch section in existing files
|
|
66
|
+
All files use `<!-- switch-scripting-context begin -->` / `<!-- switch-scripting-context end -->` markers. Re-running `init` replaces only the Switch section in existing files. Project-specific rules outside the markers are untouched.
|
|
67
67
|
|
|
68
68
|
## Using this with your coding agent
|
|
69
69
|
|
|
70
|
-
Once `init` has run, just work normally
|
|
70
|
+
Once `init` has run, just work normally. Describe what you want in plain terms and prompt as you
|
|
71
71
|
usually would. Your agent picks up the Switch context automatically (via `@import` for Claude
|
|
72
72
|
Code/Gemini, or the inlined rules + file list for the others) whenever it's working in the project,
|
|
73
73
|
and pulls in the specific API doc it needs for the task at hand on its own. You don't need to know
|
|
74
74
|
the doc file names or tell it which one to read.
|
|
75
75
|
|
|
76
76
|
A few things this gets you without asking for them by name:
|
|
77
|
-
- Scaffolding a new entry point, handling a webhook, or reading/creating datasets and jobs
|
|
77
|
+
- Scaffolding a new entry point, handling a webhook, or reading/creating datasets and jobs. The
|
|
78
78
|
agent consults the matching API reference before writing the code.
|
|
79
|
-
- Diagnosing why a script isn't behaving as expected
|
|
79
|
+
- Diagnosing why a script isn't behaving as expected. The agent knows it can locate and query
|
|
80
80
|
Switch's own log database (`ServerLogs.db3`) rather than only re-reasoning about the code.
|
|
81
|
-
- Creating, packing, or deploying a script
|
|
82
|
-
flags and
|
|
83
|
-
- Editing the script's XML declaration
|
|
84
|
-
properties (app path/
|
|
81
|
+
- Creating, packing, or deploying a script. The agent uses `SwitchScriptTool` with the documented
|
|
82
|
+
flags and behaviour, rather than hand-rolling the steps.
|
|
83
|
+
- Editing the script's XML declaration. The agent follows the documented rules and knows which
|
|
84
|
+
properties (app path/licence) are off-limits and left to SwitchScripter's GUI instead.
|
|
85
85
|
|
|
86
|
-
Re-run `init` after upgrading this package so the copied docs and generated config files catch up
|
|
87
|
-
|
|
86
|
+
Re-run `init` after upgrading this package so the copied docs and generated config files catch up.
|
|
87
|
+
See [CHANGELOG.md](https://cdn.jsdelivr.net/npm/@enfocussw/switch-scripting-context@25.11.0-beta.14/CHANGELOG.md) for what changed.
|
|
88
88
|
|
|
89
89
|
## Options
|
|
90
90
|
|
|
@@ -130,23 +130,24 @@ npm install --save-dev "https://github.com/enfocus-switch/types-switch-scripting
|
|
|
130
130
|
|
|
131
131
|
The `switch-docs/` folder contains:
|
|
132
132
|
|
|
133
|
-
- `switch-scripting.md
|
|
134
|
-
- `switch-api/api-
|
|
135
|
-
- `switch-api/api-
|
|
136
|
-
- `switch-api/api-
|
|
137
|
-
- `switch-api/api-
|
|
138
|
-
- `switch-api/api-
|
|
139
|
-
- `switch-api/api-
|
|
140
|
-
- `switch-api/api-
|
|
141
|
-
- `switch-api/api-
|
|
142
|
-
- `switch-api/api-
|
|
143
|
-
- `switch-api/api-script-
|
|
144
|
-
- `switch-api/api-
|
|
145
|
-
- `switch-api/api-
|
|
146
|
-
- `switch-api/api-
|
|
147
|
-
- `switch-api/api-
|
|
148
|
-
- `switch-api/api-
|
|
149
|
-
- `switch-api/api-
|
|
150
|
-
- `switch-api/api-
|
|
151
|
-
- `switch-api/api-
|
|
152
|
-
- `switch-api/api-
|
|
133
|
+
- `switch-scripting.md`: master index with execution environment rules and "load when" routing table
|
|
134
|
+
- `switch-api/api-project-planning.md`: pre-scaffolding checklist covering Script vs App, job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm dependencies, Appstore competition risk
|
|
135
|
+
- `switch-api/api-entry-points.md`: all entry point signatures and when each is called
|
|
136
|
+
- `switch-api/api-job.md`: `Job` class signatures for routing, file access, child jobs, private data, datasets
|
|
137
|
+
- `switch-api/api-flow-element.md`: `FlowElement`: properties, connections, job creation, logging
|
|
138
|
+
- `switch-api/api-switch.md`: `Switch` global: global data, webhooks, abort, server utilities
|
|
139
|
+
- `switch-api/api-connection.md`: `Connection`: type, properties, file count
|
|
140
|
+
- `switch-api/api-http.md`: `HttpRequest` / `HttpResponse` and webhook pattern
|
|
141
|
+
- `switch-api/api-enums.md`: all enums with string values (`LogLevel`, `AccessLevel`, `Scope`, etc.)
|
|
142
|
+
- `switch-api/api-document-classes.md`: `PdfDocument`, `ImageDocument`, `XmlDocument`, `XmpDocument`
|
|
143
|
+
- `switch-api/api-script-declaration.md`: XML declaration reference
|
|
144
|
+
- `switch-api/api-script-structure.md`: script folder contents, manifest format, Node.js version per Switch release, Script vs App
|
|
145
|
+
- `switch-api/api-tooling.md`: SwitchScriptTool commands, script folder vs package, build and deployment
|
|
146
|
+
- `switch-api/api-debugging.md`: enabling debug mode, debuggable entry points, VS Code attach
|
|
147
|
+
- `switch-api/api-logging.md`: log levels, when/what to log, `console.log` limitation, common gotchas
|
|
148
|
+
- `switch-api/api-logs-and-dataroot.md`: locating the application data root, querying `ServerLogs.db3` directly to diagnose a script
|
|
149
|
+
- `switch-api/api-vscode.md`: type declarations, tsconfig for TypeScript 6, ESLint rules
|
|
150
|
+
- `switch-api/api-property-editors.md`: property editor types and string return values
|
|
151
|
+
- `switch-api/api-job-patterns.md`: `Job` rules and gotchas covering file access semantics, temp cleanup, routing rules, child jobs, executor limits
|
|
152
|
+
- `switch-api/api-execution-environment.md`: execution modes, process model, state persistence across jobs, error handling, npm/native module constraints
|
|
153
|
+
- `switch-api/api-app-guidelines.md`: pre-publish checklist for Appstore apps covering property naming/tooltips/editors, entry point and sendTo consistency, logging quality, packaging, app-only submission rules
|
|
@@ -86,6 +86,16 @@ Called when a job arrives. Must eventually call a `job.sendTo*()` or `job.fail()
|
|
|
86
86
|
[api-script-declaration.md](api-script-declaration.md#built-in-elementfields). Never leave an empty
|
|
87
87
|
`jobArrived` or `timerFired` in the script — remove the function entirely if it does nothing.
|
|
88
88
|
|
|
89
|
+
**Gotcha: a flow restart replays every queued job through `jobArrived` again.** This includes a job
|
|
90
|
+
whose real processing was deferred elsewhere, such as a job registered in global data and actually
|
|
91
|
+
handled later in `timerFired`. `jobArrived` does not skip a job just because it was already
|
|
92
|
+
registered on a previous run; if the element still has a large backlog queued when the flow
|
|
93
|
+
restarts, every one of those jobs fires `jobArrived` again, and working through a long backlog this
|
|
94
|
+
way can take a long time even when each invocation only needs to recognize the job as already
|
|
95
|
+
registered and return. A script that defers processing this way must check global data at the top
|
|
96
|
+
of `jobArrived` and return immediately for a job already registered there, rather than assuming
|
|
97
|
+
`jobArrived` fires exactly once per job.
|
|
98
|
+
|
|
89
99
|
```ts
|
|
90
100
|
async function abort(s: Switch, flowElement: FlowElement, job: Job, abortData: any): Promise<void>
|
|
91
101
|
```
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
# Project Planning
|
|
2
|
+
|
|
3
|
+
A pre-scaffolding checklist for a new script or app. Work through this with the user before
|
|
4
|
+
creating any files. The goal is to make a few decisions deliberately up front, because retrofitting
|
|
5
|
+
them after code exists is expensive: password protection and localization for an app, path handling
|
|
6
|
+
for a second target OS, synchronizing shared-resource access for concurrency, or restructuring entry
|
|
7
|
+
points around a job-processing approach chosen too casually.
|
|
8
|
+
|
|
9
|
+
Two items below are direct questions for the user. The rest are not questions to ask upfront; they
|
|
10
|
+
are checks the agent runs against what's actually being built, raised only when they become
|
|
11
|
+
relevant.
|
|
12
|
+
|
|
13
|
+
## Ask the user directly
|
|
14
|
+
|
|
15
|
+
### 1. Script or App?
|
|
16
|
+
|
|
17
|
+
Ask whether this is for private or internal use (a plain `Script`, distributed freely) or intended
|
|
18
|
+
for the Enfocus Appstore (an `App`). See
|
|
19
|
+
[api-script-structure.md § Script vs App](api-script-structure.md#script-vs-app) for what differs.
|
|
20
|
+
|
|
21
|
+
This answer gates several items below:
|
|
22
|
+
|
|
23
|
+
- **App**: localization, password protection, `Name`-never-changes discipline, `Concurrent`-by-default
|
|
24
|
+
expectation, icon/keywords, and the version-baseline and Appstore-competition checks further down
|
|
25
|
+
all apply. See [api-app-guidelines.md](api-app-guidelines.md) for the full pre-publish checklist,
|
|
26
|
+
most of which is worth designing toward from the start rather than retrofitting later.
|
|
27
|
+
- **Script**: none of the app-only items apply. Keep it simple and don't raise app concerns for a
|
|
28
|
+
plain script.
|
|
29
|
+
|
|
30
|
+
If App, also ask which languages it must support. English is required; more than one language is
|
|
31
|
+
preferable, see [api-app-guidelines.md § Localization](api-app-guidelines.md#localization).
|
|
32
|
+
|
|
33
|
+
### 2. What should job processing look like in their flow?
|
|
34
|
+
|
|
35
|
+
Ask about job handling at a functional level: what should happen when a job arrives, does anything
|
|
36
|
+
need to wait on an external process or resource, could more than one job at a time contend for a
|
|
37
|
+
shared resource. Don't ask the user to pick entry points or connection types directly. Translate the
|
|
38
|
+
answer into a concrete proposal (which entry points, which `sendTo*()` methods, whether `jobArrived`
|
|
39
|
+
alone is enough or work must be deferred to `timerFired`) using
|
|
40
|
+
[api-entry-points.md](api-entry-points.md) and
|
|
41
|
+
[api-job-patterns.md § Sending jobs](api-job-patterns.md#sending-jobs), and be upfront about
|
|
42
|
+
limitations and tradeoffs so the user can make an informed choice, rather than silently picking an
|
|
43
|
+
approach.
|
|
44
|
+
|
|
45
|
+
If the design defers job processing to `timerFired` via global data, say explicitly that a flow
|
|
46
|
+
restart replays every queued job through `jobArrived` again, and the script must recognize and skip
|
|
47
|
+
an already-registered job quickly, or a large backlog is slow to clear, see
|
|
48
|
+
[api-entry-points.md § Job processing](api-entry-points.md#job-processing).
|
|
49
|
+
|
|
50
|
+
## Evaluate and flag, don't ask upfront
|
|
51
|
+
|
|
52
|
+
### Target OS
|
|
53
|
+
|
|
54
|
+
Switch Server runs on Windows and macOS. Default to writing platform-independent code (the `path`
|
|
55
|
+
module, no hardcoded separators, see
|
|
56
|
+
[api-job-patterns.md § Platform-independent paths](api-job-patterns.md#platform-independent-paths))
|
|
57
|
+
without asking. Only raise target OS as an explicit question once the script needs OS-specific code,
|
|
58
|
+
bundles a native binary, or ships a platform-specific package build, since only then does the answer
|
|
59
|
+
change anything.
|
|
60
|
+
|
|
61
|
+
### Switch version baseline (apps only)
|
|
62
|
+
|
|
63
|
+
Once Script vs App is answered as App, ask or infer the oldest Switch version the app must support.
|
|
64
|
+
This sets the Node.js baseline (see
|
|
65
|
+
[api-script-structure.md § Node.js version per Switch version](api-script-structure.md#nodejs-version-per-switch-version))
|
|
66
|
+
and which SwitchScripter build is needed to produce a compatible `.enfpack`. Don't ask this for a
|
|
67
|
+
plain script.
|
|
68
|
+
|
|
69
|
+
### Concurrency
|
|
70
|
+
|
|
71
|
+
Default to `Concurrent` execution; it's the preferred choice for apps per
|
|
72
|
+
[api-app-guidelines.md § Top-level declaration properties](api-app-guidelines.md#top-level-declaration-properties).
|
|
73
|
+
Don't ask the user to choose upfront. Only raise `Serialized`, and explain why, when the design has
|
|
74
|
+
an actual reason to need it: a third-party application or shared resource that can't tolerate
|
|
75
|
+
concurrent access, or an API the script drives that isn't safe to call in parallel. See
|
|
76
|
+
[api-execution-environment.md § Execution modes](api-execution-environment.md#execution-modes).
|
|
77
|
+
|
|
78
|
+
### Native or binary npm dependencies
|
|
79
|
+
|
|
80
|
+
A file-based script or app that ends up on the ESM bundling path cannot use native (binary) Node
|
|
81
|
+
addons at all, see
|
|
82
|
+
[api-execution-environment.md § Native (binary) addons are not supported](api-execution-environment.md#native-binary-addons-are-not-supported).
|
|
83
|
+
If a planned dependency needs one, for example `sharp` or native `sqlite3` bindings, say so before
|
|
84
|
+
the user commits to that library, and suggest a pure JavaScript alternative or a workaround, such as
|
|
85
|
+
shelling out to an external binary, see
|
|
86
|
+
[api-job-patterns.md § Driving a third-party CLI application](api-job-patterns.md#driving-a-third-party-cli-application),
|
|
87
|
+
where one exists.
|
|
88
|
+
|
|
89
|
+
### Appstore competition risk (apps only)
|
|
90
|
+
|
|
91
|
+
An app whose core functionality duplicates an existing Switch module without requiring that module
|
|
92
|
+
risks Appstore rejection. For example, an app that performs database CRUD operations without
|
|
93
|
+
requiring the Database Module competes directly with it. If the planned app looks like it falls into
|
|
94
|
+
this category, say so before significant effort is spent, and suggest either gating the app behind
|
|
95
|
+
the relevant module license or contacting Enfocus to check before proceeding.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
This checklist stops at planning. Once these are answered, move to
|
|
100
|
+
[api-script-structure.md](api-script-structure.md) to scaffold the project.
|
package/docs/switch-scripting.md
CHANGED
|
@@ -11,6 +11,7 @@ Detailed API docs are in `docs/switch-api/`:
|
|
|
11
11
|
|
|
12
12
|
| File | Contents | Load when |
|
|
13
13
|
|---|---|---|
|
|
14
|
+
| `switch-api/api-project-planning.md` | Pre-scaffolding checklist: Script vs App, job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm dependencies, Appstore competition risk | Starting a new script or app, before scaffolding any files |
|
|
14
15
|
| `switch-api/api-entry-points.md` | All entry point signatures, constraints, and when each is called | Scaffolding a script, adding/editing an entry point, or making any edit to main.ts/main.js |
|
|
15
16
|
| `switch-api/api-switch.md` | `Switch` (`s`) — global data, webhooks, abort, server utilities | Using global data, webhooks, abort, or server settings |
|
|
16
17
|
| `switch-api/api-flow-element.md` | `FlowElement` — properties, connections, job creation, logging | Reading properties, creating jobs, logging, connections |
|
|
@@ -32,7 +33,11 @@ Detailed API docs are in `docs/switch-api/`:
|
|
|
32
33
|
| `switch-api/api-app-guidelines.md` | Pre-publish checklist for Appstore apps: property naming/tooltips/editors, entry point and sendTo consistency, logging quality, packaging, and the app-only submission rules (localization, signed universal macOS binaries) | Preparing a script for publication as an app, or reviewing one against Appstore submission criteria |
|
|
33
34
|
|
|
34
35
|
## Key rules
|
|
36
|
+
- Before scaffolding a new script or app, work through `switch-api/api-project-planning.md` with the user.
|
|
35
37
|
- Always consult the API reference files above before writing or modifying script code.
|
|
38
|
+
- To find documented behavioural pitfalls before writing code in an area, grep `docs/switch-api/`
|
|
39
|
+
for `known issue`, `gotcha`, `quirk`, `caveat` (case-insensitive) — every documented pitfall uses
|
|
40
|
+
one of these four terms.
|
|
36
41
|
- Do not `export` entry point functions. Declare them with the literal `function` keyword at top
|
|
37
42
|
level — arrow functions, `exports.name = ...`, and class methods are invisible to Switch.
|
|
38
43
|
- Switch discovers entry points with a regex, not a parser. Never write a string literal whose
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@enfocussw/switch-scripting-context",
|
|
3
|
-
"version": "25.11.0-beta.
|
|
3
|
+
"version": "25.11.0-beta.14",
|
|
4
4
|
"description": "AI coding assistant context for Enfocus Switch scripting (Node.js/TypeScript)",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"switch",
|
|
@@ -27,14 +27,17 @@
|
|
|
27
27
|
"docs/",
|
|
28
28
|
"!docs/superpowers",
|
|
29
29
|
"!docs/temp",
|
|
30
|
+
"!docs/adr",
|
|
30
31
|
"CHANGELOG.md"
|
|
31
32
|
],
|
|
32
33
|
"scripts": {
|
|
33
34
|
"build": "tsc -p tsconfig.json",
|
|
34
35
|
"build:test": "tsc src/init.test.ts --outDir dist --target ES2020 --module commonjs --lib ES2020 --types node --strict --esModuleInterop --skipLibCheck",
|
|
35
|
-
"test": "npm run build && npm run build:test && node dist/init.test.js",
|
|
36
|
-
"prepack": "npm run build",
|
|
37
|
-
"postpack": "node -e \"const fs=require('fs');const version=process.env.npm_package_version;const scoped=process.env.npm_package_name.replace(/^@/,'').replace('/','-')+'-'+version+'.tgz';const unscoped=process.env.npm_package_name.replace(/^@[^/]+\\//,'')+'-'+version+'.tgz';if(scoped!==unscoped&&fs.existsSync(scoped))fs.renameSync(scoped,unscoped);\""
|
|
36
|
+
"test": "npm run build && npm run build:test && node dist/init.test.js && node scripts/check-prose.js && node scripts/check-gotcha-tags.js",
|
|
37
|
+
"prepack": "npm run build && node scripts/readme-links.js --publish",
|
|
38
|
+
"postpack": "node scripts/readme-links.js --restore && node -e \"const fs=require('fs');const version=process.env.npm_package_version;const scoped=process.env.npm_package_name.replace(/^@/,'').replace('/','-')+'-'+version+'.tgz';const unscoped=process.env.npm_package_name.replace(/^@[^/]+\\//,'')+'-'+version+'.tgz';if(scoped!==unscoped&&fs.existsSync(scoped))fs.renameSync(scoped,unscoped);\"",
|
|
39
|
+
"lint:prose": "node scripts/check-prose.js",
|
|
40
|
+
"lint:gotchas": "node scripts/check-gotcha-tags.js"
|
|
38
41
|
},
|
|
39
42
|
"author": "Sam Wallace",
|
|
40
43
|
"license": "ISC",
|