face-up 0.0.0 → 0.0.2

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.
Files changed (46) hide show
  1. package/.gitmodules +3 -0
  2. package/.kiro/steering/project-context.md +17 -0
  3. package/.vscode/settings.json +3 -0
  4. package/FaceUp.js +305 -0
  5. package/README.md +162 -2
  6. package/imports.html +8 -0
  7. package/package.json +30 -20
  8. package/tests/test1.html +115 -0
  9. package/types/.kiro/specs/conversion-template/README.md +128 -0
  10. package/types/.kiro/specs/conversion-template/design.md +360 -0
  11. package/types/.kiro/specs/conversion-template/requirements.md +191 -0
  12. package/types/.kiro/specs/conversion-template/tasks.md +174 -0
  13. package/types/.kiro/steering/coding-standards.md +17 -0
  14. package/types/.kiro/steering/conversion-guide.md +103 -0
  15. package/types/.kiro/steering/declarative-configuration.md +108 -0
  16. package/types/.kiro/steering/emc-json-serializability.md +306 -0
  17. package/types/EnhancementConversionInstructions.md +1626 -0
  18. package/types/LICENSE +21 -0
  19. package/types/NewCustomElementFeature.md +673 -0
  20. package/types/NewEnhancementInstructions.md +395 -0
  21. package/types/README.md +2 -0
  22. package/types/agrace/types.d.ts +11 -0
  23. package/types/assign-gingerly/types.d.ts +328 -0
  24. package/types/be-a-beacon/types.d.ts +17 -0
  25. package/types/be-bound/types.d.ts +61 -0
  26. package/types/be-buttoned-up/types.d.ts +19 -0
  27. package/types/be-clonable/types.d.ts +36 -0
  28. package/types/be-committed/types.d.ts +22 -0
  29. package/types/be-decked-with/types.d.ts +26 -0
  30. package/types/be-delible/types.d.ts +25 -0
  31. package/types/be-reflective/types.d.ts +80 -0
  32. package/types/be-render-neutral/types.d.ts +29 -0
  33. package/types/be-typed/types.d.ts +31 -0
  34. package/types/do-inc/types.d.ts +56 -0
  35. package/types/do-invoke/types.d.ts +38 -0
  36. package/types/do-merge/types.d.ts +28 -0
  37. package/types/do-toggle/types.d.ts +31 -0
  38. package/types/face-up/types.d.ts +104 -0
  39. package/types/global.d.ts +29 -0
  40. package/types/id-generation/types.d.ts +26 -0
  41. package/types/inferencer/types.d.ts +46 -0
  42. package/types/mount-observer/types.d.ts +363 -0
  43. package/types/nested-regex-groups/types.d.ts +101 -0
  44. package/types/roundabout/types.d.ts +255 -0
  45. package/types/time-ticker/types.d.ts +66 -0
  46. package/types/truth-sourcer/types.d.ts +46 -0
@@ -0,0 +1,174 @@
1
+ # Tasks: Convert [PROJECT_NAME] to Modern Architecture
2
+
3
+ ## Task List
4
+
5
+ - [ ] 1. Migrate Type Definitions
6
+ - [ ] 1.1 Check if ts-refs folder exists
7
+ - [ ] 1.2 Copy ts-refs/[project-name] to types/[project-name]
8
+ - [ ] 1.3 Delete ts-refs folder
9
+ - [ ] 1.4 Verify types accessible at new location
10
+
11
+ - [ ] 2. Archive Legacy Implementation
12
+ - [ ] 2.1 Create legacy folder if needed
13
+ - [ ] 2.2 Empty legacy folder if it exists
14
+ - [ ] 2.3 Move all .js files to legacy (except package*.json)
15
+ - [ ] 2.4 Move all .mjs files to legacy
16
+ - [ ] 2.5 Move all .json files to legacy (except package*.json)
17
+ - [ ] 2.6 Verify legacy folder contains complete implementation
18
+
19
+ - [ ] 3. Update package.json
20
+ - [ ] 3.1 Update scripts section with build, serve, test, safari, update
21
+ - [ ] 3.2 Update dependencies to be-hive, mount-observer, and roundabout-lib
22
+ - [ ] 3.3 Update devDependencies to @playwright/test and spa-ssi
23
+ - [ ] 3.4 Run npm run update
24
+ - [ ] 3.5 Verify npm install succeeds
25
+
26
+ - [ ] 4. Configure Import Maps
27
+ - [ ] 4.1 Create or replace imports.html
28
+ - [ ] 4.2 Add assign-gingerly mapping
29
+ - [ ] 4.3 Add project mapping to "/"
30
+ - [ ] 4.4 Add be-hive mapping
31
+ - [ ] 4.5 Add mount-observer mapping
32
+ - [ ] 4.6 Add roundabout-lib mapping
33
+
34
+ - [ ] 5. Establish Coding Standards
35
+ - [ ] 5.1 Create .kiro/steering directory
36
+ - [ ] 5.2 Create coding-standards.md
37
+ - [ ] 5.3 Document import map conventions
38
+ - [ ] 5.4 Document file extension conventions
39
+ - [ ] 5.5 Document TypeScript support conventions
40
+
41
+ - [ ] 6. Modernize Type Definitions
42
+ - [ ] 6.1 Open types/[project-name]/types.d.ts
43
+ - [ ] 6.2 Remove import statements
44
+ - [ ] 6.3 Remove extends IEnhancement from EndUserProps
45
+ - [ ] 6.4 Add enhancedElement: Element to AllProps
46
+ - [ ] 6.5 Remove BAP type alias
47
+ - [ ] 6.6 Replace BAP with AP in Actions interface
48
+ - [ ] 6.7 Verify no TypeScript errors
49
+
50
+ - [ ] 7. Create Build Configuration
51
+ - [ ] 7.1 Create emc.mjs file
52
+ - [ ] 7.2 Add imports and type annotations
53
+ - [ ] 7.3 Configure enhConfig with enhKey and spawn
54
+ - [ ] 7.4 Configure withAttrs for attribute mapping
55
+ - [ ] 7.5 Add weakRef configuration with enhancedElement
56
+ - [ ] 7.6 Copy actions from legacy static config to customData
57
+ - [ ] 7.7 Add 'enhancedElement' to ifAllOf for actions that reference it
58
+ - [ ] 7.8 Copy handlers from legacy static config to customData
59
+ - [ ] 7.9 Copy compacts from legacy static config to customData
60
+ - [ ] 7.10 Add render function
61
+ - [ ] 7.11 Add console.log(render())
62
+ - [ ] 7.12 Test build: npm run build (should generate emc.json)
63
+
64
+ - [ ] 8. Configure VS Code
65
+ - [ ] 8.1 Create .vscode folder if needed
66
+ - [ ] 8.2 Create or open .vscode/settings.json
67
+ - [ ] 8.3 Add file nesting patterns
68
+ - [ ] 8.4 Enable file nesting
69
+ - [ ] 8.5 Verify JSON files nest under .mjs files in explorer
70
+
71
+ - [ ] 8a. Configure Auto-Build Hook (Optional)
72
+ - [ ] 8a.1 Create .kiro/hooks folder if needed
73
+ - [ ] 8a.2 Create auto-build-config.kiro.hook
74
+ - [ ] 8a.3 Configure fileEdited event for emc.mjs and emoji .mjs
75
+ - [ ] 8a.4 Configure runCommand action with npm run build
76
+ - [ ] 8a.5 Test by saving emc.mjs and verifying JSON regenerates
77
+
78
+ - [ ] 9. Create Modern Enhancement Class
79
+ - [ ] 9.1 Create be-[project-name].js file
80
+ - [ ] 9.2 Add imports (emc.json with type annotation, types)
81
+ - [ ] 9.3 Add class declaration
82
+ - [ ] 9.4 Add constructor with enhancedElement, ctx, initVals parameters
83
+ - [ ] 9.5 Add init method with enhancedElement parameter
84
+ - [ ] 9.6 Add roundabout integration in init
85
+ - [ ] 9.7 Add enhancedElement to assignGingerly call
86
+ - [ ] 9.8 Add default values to init via assignGingerly
87
+ - [ ] 9.9 Copy action methods from legacy
88
+ - [ ] 9.10 Replace BAP with AP in all methods
89
+ - [ ] 9.11 Remove legacy imports
90
+ - [ ] 9.12 Export class
91
+ - [ ] 9.13 Verify no TypeScript errors
92
+
93
+ - [ ] 10. Create Emoji Shorthand (Optional)
94
+ - [ ] 10.1 Check README for emoji in title
95
+ - [ ] 10.2 Create [emoji].mjs file (if emoji exists)
96
+ - [ ] 10.3 Import emc.json
97
+ - [ ] 10.4 Configure enhConfig override
98
+ - [ ] 10.5 Add render function
99
+ - [ ] 10.6 Add console.log(render())
100
+ - [ ] 10.7 Test build: npm run build (should generate [emoji].json)
101
+
102
+ - [ ] 11. Verification
103
+ - [ ] 11.1 Run npm run build (should succeed)
104
+ - [ ] 11.2 Verify emc.json generated
105
+ - [ ] 11.3 Verify [emoji].json generated (if applicable)
106
+ - [ ] 11.4 Run npm test (should pass)
107
+ - [ ] 11.5 Check for TypeScript errors
108
+ - [ ] 11.6 Verify legacy folder is complete
109
+ - [ ] 11.7 Compare behavior with legacy implementation
110
+
111
+ ## Task Dependencies
112
+
113
+ ```
114
+ 1 (Types) → 6 (Modernize Types)
115
+ 2 (Archive) → 7 (Build Config), 9 (Enhancement Class)
116
+ 3 (package.json) → 7 (Build Config)
117
+ 4 (imports.html) → 9 (Enhancement Class)
118
+ 5 (Standards) → 9 (Enhancement Class)
119
+ 6 (Types) → 7 (Build Config), 9 (Enhancement Class)
120
+ 7 (Build Config) → 9 (Enhancement Class), 10 (Emoji)
121
+ 8 (VS Code) → (no dependencies, can be done anytime)
122
+ 9 (Enhancement Class) → 11 (Verification)
123
+ 10 (Emoji) → 11 (Verification)
124
+ ```
125
+
126
+ ## Execution Notes
127
+
128
+ ### Step 1: Migrate Type Definitions
129
+ - Check for ts-refs folder first
130
+ - If not found, types may already be migrated
131
+ - Verify types are accessible after migration
132
+
133
+ ### Step 2: Archive Legacy Implementation
134
+ - This is critical - don't skip
135
+ - Verify all files are moved before proceeding
136
+ - Keep package.json and package-lock.json in root
137
+
138
+ ### Step 3: Update package.json
139
+ - Note the emoji in README title for build script
140
+ - If no emoji, omit the emoji build command
141
+ - npm run update will fetch latest versions
142
+
143
+ ### Step 7: Create Build Configuration
144
+ - Reference legacy emc.js for base/branches/map
145
+ - Reference legacy be-*.js static config for actions/handlers/compacts
146
+ - Add weakRef configuration with enhancedElement at minimum
147
+ - For actions with ifAllOf, add 'enhancedElement' if the method code references it
148
+ - Don't copy propDefaults or propInfo
149
+ - Test the build immediately after creating
150
+
151
+ ### Step 9: Create Modern Enhancement Class
152
+ - No WeakRef boilerplate needed - roundabout handles it
153
+ - Constructor passes enhancedElement to init method
154
+ - Init method receives enhancedElement as parameter
155
+ - Add enhancedElement to assignGingerly call before other defaults
156
+ - Copy action methods carefully
157
+ - Replace all BAP with AP
158
+ - Keep method implementations the same
159
+ - Remove any be-enhanced specific code
160
+
161
+ ### Step 10: Create Emoji Shorthand
162
+ - Only if emoji exists in README title
163
+ - Very simple - just overrides enhKey and base
164
+ - Test build to verify JSON generation
165
+
166
+ ### Step 11: Verification
167
+ - This is the final validation
168
+ - All tests should pass
169
+ - Build should succeed
170
+ - No TypeScript errors
171
+
172
+ ## Reference
173
+
174
+ For detailed instructions on each step, see: `#[[file:../../ConversionInstructions.md]]`
@@ -0,0 +1,17 @@
1
+ # Coding Standards
2
+
3
+ ## JavaScript Module Conventions
4
+
5
+ ### Import Maps
6
+ - Use import maps with explicit, bare specifiers ending with `*.js` for all JavaScript references that run in the browser
7
+ - Example: `"be-hive/": "/node_modules/be-hive/"`
8
+
9
+ ### File Extensions
10
+ - Use `*.mjs` files exclusively for npm build scripts, not for browser code
11
+ - Use `*.js` files (not `*.ts`) for all browser-executable code
12
+ - Enable TypeScript support in `*.js` files via `@ts-check` directive at the top of files
13
+
14
+ ### TypeScript Support
15
+ - Add `// @ts-check` at the beginning of JavaScript files to enable TypeScript checking
16
+ - Use JSDoc comments for type annotations when needed
17
+ - Leverage type definitions from the `types` submodule
@@ -0,0 +1,103 @@
1
+ # be-* Enhancement Conversion Guide
2
+
3
+ ## Purpose
4
+
5
+ This steering file provides guidance for converting legacy "be-*" enhancement projects to the modern architecture. When a user requests help with converting a be-* project, use this guide to structure the conversion process.
6
+
7
+ **Important:** This guide is specifically for **enhancements** (declarative behaviors added to existing HTML elements via attributes). It does NOT apply to custom elements.
8
+
9
+ ## Reference Documentation
10
+
11
+ - **Converting legacy enhancements:** `EnhancementConversionInstructions.md` in the types repository root
12
+ - **Creating new enhancements from scratch:** `NewEnhancementInstructions.md` in the types repository root
13
+
14
+ Always reference the appropriate document based on whether the project is a legacy conversion or a brand new enhancement.
15
+
16
+ ## Conversion Approach
17
+
18
+ ### When to Use Spec-Based Conversion
19
+
20
+ For systematic, trackable conversions, create a spec using the conversion template:
21
+ - User wants to track progress through the conversion
22
+ - User wants to review each step before proceeding
23
+ - User is learning the conversion process
24
+ - Multiple people are involved in the conversion
25
+
26
+ ### When to Use Direct Conversion
27
+
28
+ For quick, automated conversions:
29
+ - User is familiar with the conversion process
30
+ - User wants rapid execution without step-by-step review
31
+ - The project is straightforward with no special cases
32
+
33
+ ## Key Principles
34
+
35
+ 1. **Preserve Legacy Code**: Always move existing implementation to the `legacy` folder before making changes
36
+ 2. **Follow the Order**: The conversion steps have dependencies - follow them in sequence
37
+ 3. **Verify Each Step**: After each major step, verify the changes work as expected
38
+ 4. **Reference Examples**: Point to **be-clonable** (most up-to-date), be-committed, and be-decked-with as reference implementations. Prefer be-clonable as it has the latest architectural improvements. Note: be-a-beacon is too simple to serve as a good example - it doesn't use roundabout due to its minimal requirements.
39
+
40
+ ## Common Patterns
41
+
42
+ ### Project Structure Recognition
43
+
44
+ Identify legacy projects by these characteristics:
45
+ - Has `be-enhanced` or `trans-render` dependencies
46
+ - Class extends `BE` from be-enhanced
47
+ - Has static `config` object in the enhancement class
48
+ - Uses `emc.js` with `base`, `branches`, `map` pattern
49
+ - Has `ts-refs` submodule for types
50
+
51
+ ### Modern Architecture Indicators
52
+
53
+ Recognize already-converted projects by:
54
+ - Has `be-hive` and `roundabout-lib` dependencies
55
+ - Has `emc.mjs` build script
56
+ - Has `types` submodule (not `ts-refs`)
57
+ - Class doesn't extend anything
58
+ - Uses constructor with `enhancedElement`, `ctx`, `initVals` parameters
59
+
60
+ ## Conversion Workflow
61
+
62
+ When a user asks to convert a be-* project:
63
+
64
+ 1. **Assess the project**: Determine if it's legacy or already converted
65
+ 2. **Offer spec creation**: Ask if they want a tracked conversion (spec) or direct conversion
66
+ 3. **Execute systematically**: Follow the 10 steps in ConversionInstructions.md
67
+ 4. **Run npm run update**: After Step 3 (updating package.json), ALWAYS run `npm run update` to install dependencies before proceeding
68
+ 5. **Verify at milestones**: After steps 3, 7, and 10, suggest running `npm run build` and `npm test`
69
+ 6. **Reference the guide**: Point users to specific sections of ConversionInstructions.md as needed
70
+ 7. **Use be-clonable as reference**: When implementation details are unclear, refer to [be-clonable](https://github.com/bahrus/be-clonable) as it has the most refined patterns
71
+
72
+ ## Special Cases
73
+
74
+ ### No Emoji Shorthand
75
+ If the README doesn't have an emoji in the title:
76
+ - Skip Step 10 (emoji .mjs creation)
77
+ - Update package.json build script to only generate emc.json
78
+
79
+ ### Complex Static Config
80
+ If the legacy static config has unusual patterns:
81
+ - Carefully map `propDefaults` to the init method
82
+ - Preserve any custom logic in action methods
83
+ - Document any patterns that don't fit the standard conversion
84
+
85
+ ### Custom Dependencies
86
+ If the project uses trans-render utilities:
87
+ - Keep those imports in the action methods
88
+ - Don't remove them unless they're only used in static config
89
+
90
+ ## Success Criteria
91
+
92
+ A successful conversion should:
93
+ - ✅ Build without errors (`npm run build`)
94
+ - ✅ Pass existing tests (`npm test`)
95
+ - ✅ Have all legacy files in the `legacy` folder
96
+ - ✅ Have modern architecture files (emc.mjs, be-*.js, types)
97
+ - ✅ Have updated dependencies (be-hive, roundabout-lib)
98
+ - ✅ Generate valid JSON configuration files
99
+
100
+ ## File Reference
101
+
102
+ Always reference `#[[file:EnhancementConversionInstructions.md]]` for the complete step-by-step conversion instructions.
103
+ For new enhancements, reference `#[[file:NewEnhancementInstructions.md]]`.
@@ -0,0 +1,108 @@
1
+ # Declarative Configuration Principle
2
+
3
+ ## Overview
4
+
5
+ Move as much "code" out of JavaScript into JSON configuration as possible. JSON is faster to parse than JavaScript, and declarative configuration makes the code more maintainable and easier to understand.
6
+
7
+ ## When to Apply
8
+
9
+ This principle applies when:
10
+ - Creating or configuring DOM elements with known properties
11
+ - Setting element attributes, classes, or other properties
12
+ - The logic is primarily about setting values rather than complex computation
13
+
14
+ ## Pattern: Element Creation Settings
15
+
16
+ Instead of imperatively creating and configuring elements in JavaScript:
17
+
18
+ ```javascript
19
+ // ❌ Imperative approach
20
+ async addDeleteBtn(self){
21
+ // ... find or create trigger ...
22
+ if(trigger === null){
23
+ trigger = document.createElement('button');
24
+ trigger.type = 'button';
25
+ trigger.classList.add('be-delible-trigger');
26
+ trigger.ariaLabel = 'Delete this.';
27
+ trigger.title = 'Delete this.';
28
+ enhancedElement.insertAdjacentElement(triggerInsertPosition, trigger);
29
+ }
30
+ return { trigger: new WeakRef(trigger), byob };
31
+ }
32
+ ```
33
+
34
+ Move the configuration to JSON in emc.mjs:
35
+
36
+ ```javascript
37
+ // ✅ Declarative approach in emc.mjs
38
+ customData: {
39
+ customData: {
40
+ triggerSettings: {
41
+ type: 'button',
42
+ '?.classList?.add': 'be-delible-trigger',
43
+ ariaLabel: 'Delete this.',
44
+ title: 'Delete this.',
45
+ },
46
+ withMethods: ['add']
47
+ }
48
+ }
49
+ ```
50
+
51
+ Then use assignGingerly to apply the settings:
52
+
53
+ ```javascript
54
+ // ✅ Simplified JavaScript
55
+ async addDeleteBtn(self) {
56
+ // ... find or create trigger ...
57
+ if (trigger === null) {
58
+ trigger = document.createElement('button');
59
+ const {triggerSettings, withMethods} = customData.customData;
60
+ (await import('assign-gingerly/assignGingerly.js')).assignGingerly(trigger, triggerSettings, {withMethods});
61
+ enhancedElement.insertAdjacentElement(triggerInsertPosition, trigger);
62
+ }
63
+ return { trigger, resolved: true, byob };
64
+ }
65
+ ```
66
+
67
+ ## Benefits
68
+
69
+ 1. **Performance**: JSON parsing is faster than JavaScript execution
70
+ 2. **Maintainability**: Configuration is centralized and easier to modify
71
+ 3. **Clarity**: Declarative intent is clearer than imperative code
72
+ 4. **Separation of concerns**: Configuration is separate from logic
73
+
74
+ ## assignGingerly Special Syntax
75
+
76
+ The `assignGingerly` utility supports special property syntax:
77
+
78
+ - `'?.classList?.add'`: Safely calls `classList.add()` method
79
+ - `'?.classList?.remove'`: Safely calls `classList.remove()` method
80
+ - `'?.classList?.toggle'`: Safely calls `classList.toggle()` method
81
+ - Use `withMethods` option to specify which methods to enable (e.g., `{withMethods: ['add', 'remove']}`)
82
+
83
+ ## WeakRef Handling
84
+
85
+ When using roundabout's `weakRef.properties` configuration:
86
+
87
+ - Properties listed in `weakRef.properties` are automatically wrapped in WeakRef by roundabout
88
+ - In your action methods, access these properties directly (roundabout unwraps them automatically)
89
+ - Return the raw element reference, not `new WeakRef(element)` - roundabout handles the wrapping
90
+
91
+ ```javascript
92
+ // ✅ Correct - return raw element
93
+ return { trigger, resolved: true, byob };
94
+
95
+ // ❌ Wrong - don't manually wrap in WeakRef
96
+ return { trigger: new WeakRef(trigger), resolved: true, byob };
97
+ ```
98
+
99
+ ## When NOT to Apply
100
+
101
+ Don't force declarative configuration when:
102
+ - The logic involves complex conditionals or computations
103
+ - The configuration depends on runtime state that can't be known at build time
104
+ - The imperative code is actually clearer and simpler
105
+
106
+ ## Reference Implementation
107
+
108
+ See [be-clonable](https://github.com/bahrus/be-clonable/blob/baseline/emc.mjs) for a complete example of this pattern in action.