spawnpack 0.1.20 → 0.1.22

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/dist/spawnpack.js CHANGED
@@ -1764,7 +1764,7 @@ function generatePackageJson(config, versions) {
1764
1764
  };
1765
1765
  if (config.scripting === "typescript") {
1766
1766
  packageJson.devDependencies = {
1767
- dprint: "^0.49.1",
1767
+ dprint: "^0.50.2",
1768
1768
  typescript: "^5.7.3"
1769
1769
  };
1770
1770
  }
@@ -1800,18 +1800,20 @@ function generateTsConfig(config) {
1800
1800
  }
1801
1801
  function generateDprintConfig() {
1802
1802
  return {
1803
- indentWidth: 4,
1804
- lineWidth: 160,
1805
1803
  typescript: {
1806
1804
  deno: true,
1807
- indentWidth: 4,
1808
- lineWidth: 160,
1805
+ lineWidth: 100,
1806
+ useTabs: true,
1809
1807
  "module.sortImportDeclarations": "caseSensitive",
1810
1808
  "importDeclaration.sortNamedImports": "caseSensitive"
1811
1809
  },
1810
+ json: {
1811
+ lineWidth: 100,
1812
+ useTabs: true
1813
+ },
1812
1814
  excludes: ["**/node_modules", "**/*-lock.json"],
1813
1815
  plugins: [
1814
- "https://plugins.dprint.dev/typescript-0.95.12.wasm",
1816
+ "https://plugins.dprint.dev/typescript-0.95.13.wasm",
1815
1817
  "https://plugins.dprint.dev/json-0.21.0.wasm",
1816
1818
  "https://plugins.dprint.dev/markdown-0.20.0.wasm"
1817
1819
  ]
@@ -1920,7 +1922,7 @@ function generateMainTs(config) {
1920
1922
  return `import { world } from "@minecraft/server";
1921
1923
 
1922
1924
  world.afterEvents.worldLoad.subscribe(() => {
1923
- console.warn("[${config.identifier}:${config.projectId}] Addon loaded!");
1925
+ console.warn("[${config.identifier}:${config.projectId}] Addon loaded!");
1924
1926
  });
1925
1927
  `;
1926
1928
  }
@@ -2125,7 +2127,7 @@ var RP_NAMESPACED_NESTED_DIRECTORIES = [
2125
2127
  ["textures", "items"]
2126
2128
  ];
2127
2129
  function stringifyJson(value) {
2128
- return `${JSON.stringify(value, null, 4)}
2130
+ return `${JSON.stringify(value, null, "\t")}
2129
2131
  `;
2130
2132
  }
2131
2133
  async function writeJsonFile(filePath, value) {
@@ -2221,9 +2223,9 @@ async function generateProject(config) {
2221
2223
  writeJsonFile(join(rpPath, "sounds", "sound_definitions.json"), generateSoundDefinitions()),
2222
2224
  writeJsonFile(join(rpPath, "textures", "item_texture.json"), generateItemTexture(config)),
2223
2225
  writeJsonFile(join(rpPath, "textures", "terrain_texture.json"), generateTerrainTexture(config)),
2224
- writeTextFile(join(rpPath, "textures", "flipbook_textures.json"), "[]"),
2225
- writeTextFile(join(bpPath, "texts", "languages.json"), '["en_US"]'),
2226
- writeTextFile(join(rpPath, "texts", "languages.json"), '["en_US"]'),
2226
+ writeJsonFile(join(rpPath, "textures", "flipbook_textures.json"), []),
2227
+ writeJsonFile(join(bpPath, "texts", "languages.json"), ["en_US"]),
2228
+ writeJsonFile(join(rpPath, "texts", "languages.json"), ["en_US"]),
2227
2229
  writeTextFile(join(destination, ".gitignore"), generateGitignore(config)),
2228
2230
  writeTextFile(join(destination, "README.md"), generateReadme(config))
2229
2231
  ];
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "spawnpack",
3
- "version": "0.1.20",
3
+ "version": "0.1.22",
4
4
  "description": "Minecraft Bedrock addon project generator — scaffold your BP+RP in seconds",
5
5
  "author": "veedy-dev",
6
6
  "license": "MIT",
@@ -5,6 +5,12 @@
5
5
  - Prefer current Microsoft Creator documentation and versioned references on `bedrock.dev`. For Script API, also use `https://jaylydev.github.io/scriptapi-docs/latest/`. Use `wiki.bedrock.dev` for established concepts and proven implementation patterns. Confirm stable versus preview status and the target Minecraft version.
6
6
  - For other external libraries, frameworks, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.
7
7
 
8
+ ## Technical judgment
9
+
10
+ - Do not assume the user or the agent is correct. Before implementing, verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.
11
+ - If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.
12
+ - If evidence shows the requested approach is incorrect, unsafe, incompatible, unnecessarily complex, or slower than a supported alternative, explain why and recommend the better implementation. Follow the user's final choice unless it violates safety or repository constraints.
13
+
8
14
  ## Verification
9
15
 
10
16
  - After TypeScript changes, run `tsc --noEmit`.
@@ -27,7 +33,7 @@
27
33
 
28
34
  ## Performance preferences
29
35
 
30
- - Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
36
+ - Before adding `system.runInterval` polling, check the project's Script API version and current documentation for a matching event. Prefer the event when it provides the required data and timing, such as `PlayerInventoryItemChangeAfterEventSignal` instead of repeatedly scanning every player's inventory or hotbar for item changes. Poll only when no suitable event exists or the event cannot represent the required behavior; then minimize the polling frequency, players, slots, and work performed.
31
37
  - In hot loops, iterate maps directly with `for (const value of map.values())`. Do not spread maps into temporary arrays or iterate entry pairs when values or keys are enough.
32
38
  - Cache stable configuration in memory and persist only when values actually change.
33
39
  - Guard invalid states with conditions before they reach the API — unloaded chunks or locations, invalid or despawned entities, etc so Minecraft Bedrock does not throw. Guards are required wherever a state check is possible. Prefer guards over `try-catch`; `try-catch` is allowed only for documented or observed unguardable failures, and must perform meaningful recovery — never rely on it as routine control flow or swallow errors.
@@ -5,6 +5,12 @@
5
5
  - Prefer current Microsoft Creator documentation and versioned references on `bedrock.dev`. For Script API, also use `https://jaylydev.github.io/scriptapi-docs/latest/`. Use `wiki.bedrock.dev` for established concepts and proven implementation patterns. Confirm stable versus preview status and the target Minecraft version.
6
6
  - For other external libraries, frameworks, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.
7
7
 
8
+ ## Technical judgment
9
+
10
+ - Do not assume the user or the agent is correct. Before implementing, verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.
11
+ - If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.
12
+ - If evidence shows the requested approach is incorrect, unsafe, incompatible, unnecessarily complex, or slower than a supported alternative, explain why and recommend the better implementation. Follow the user's final choice unless it violates safety or repository constraints.
13
+
8
14
  ## Verification
9
15
 
10
16
  - After TypeScript changes, run `tsc --noEmit`.
@@ -27,7 +33,7 @@
27
33
 
28
34
  ## Performance preferences
29
35
 
30
- - Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
36
+ - Before adding `system.runInterval` polling, check the project's Script API version and current documentation for a matching event. Prefer the event when it provides the required data and timing, such as `PlayerInventoryItemChangeAfterEventSignal` instead of repeatedly scanning every player's inventory or hotbar for item changes. Poll only when no suitable event exists or the event cannot represent the required behavior; then minimize the polling frequency, players, slots, and work performed.
31
37
  - In hot loops, iterate maps directly with `for (const value of map.values())`. Do not spread maps into temporary arrays or iterate entry pairs when values or keys are enough.
32
38
  - Cache stable configuration in memory and persist only when values actually change.
33
39
  - Guard invalid states with conditions before they reach the API — unloaded chunks or locations, invalid or despawned entities, etc so Minecraft Bedrock does not throw. Guards are required wherever a state check is possible. Prefer guards over `try-catch`; `try-catch` is allowed only for documented or observed unguardable failures, and must perform meaningful recovery — never rely on it as routine control flow or swallow errors.