bimplus-renderer 1.8.41-babel-webpack1.0 → 1.8.41

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.
@@ -0,0 +1,14 @@
1
+ ---
2
+ applyTo: "**/webpack*.js, **/package.json, **/scripts/**/*.js"
3
+ ---
4
+
5
+ # ES2019 Bundle Compatibility
6
+
7
+ Keep the published renderer bundle parseable by downstream Webpack 4 consumers, whose parser may stop at ES2020 syntax.
8
+
9
+ - Babel 8 `@babel/preset-env` defaults to modern browser targets. Set explicit targets below the syntax level that downstream tooling supports; for the current renderer use Chrome 79, Firefox 72, Safari 13, and Edge 79.
10
+ - Apply Babel to bundled dependencies that can contain newer syntax, especially `three` and `web-ifc`. Do not exclude these packages from the production Babel rule.
11
+ - `target: ['web', 'es2019']` and Terser's `ecma: 2019` control Webpack output and minification; neither transpiles syntax already present in input modules. Keep the Babel transform as the source-syntax compatibility step.
12
+ - Babel preset-env does not lower BigInt literal syntax. If a dependency introduces `1n` literals, rewrite only the literals to `BigInt("1")` calls so an ES2019 parser can read the bundle. This does not polyfill BigInt; runtime use still requires native BigInt support.
13
+ - Keep an Acorn check using `ecmaVersion: 2019` on the generated `dist/bimplus-renderer.js` in every production build/publish path. It should run after Webpack emits the bundle and before copying or publishing artifacts.
14
+ - Verify changes with the production Webpack build followed by `npm run check-es2019`. A successful Webpack/Terser build alone does not establish ES2019 compatibility.
@@ -0,0 +1,79 @@
1
+ ---
2
+ description: "Use when writing or updating JSDoc comments, documenting renderer API classes/methods, or generating API documentation (build-doc, build-docMd, Confluence export). Covers required tags, visibility rules, and validation."
3
+ applyTo: "src/**/*.js"
4
+ ---
5
+
6
+ # JSDoc Usage for API Documentation
7
+
8
+ The public API docs are generated from JSDoc comments in `src/` via JSDoc 4 (`jsdoc.json`) with the custom plugin `scripts/jsdoc-class-ownership-plugin.js` and `scripts/generate-api-markdown.js`. Follow these rules so symbols land correctly in `documentation/Bimplus_Renderer_doc.md` and the HTML docs.
9
+
10
+ ## What gets published
11
+
12
+ A symbol only appears in generated API docs when **all** of these hold:
13
+
14
+ - It has a JSDoc comment with a non-empty description.
15
+ - It is not marked `@private` and its name does not start with `_` (both are excluded automatically).
16
+ - Its kind is a container (`class`, `namespace`, `module`) or a member kind (`function`, `member`, `constant`, `event`, `typedef`, `callback`).
17
+ - Member symbols belong to a documented container — document the class itself, or its methods will be dropped silently.
18
+
19
+ ## Required comment structure
20
+
21
+ Start with a short description, then tags in this order: visibility, structural tags, `@param`, `@returns`.
22
+
23
+ ```js
24
+ /**
25
+ * Set the dimension line visibility.
26
+ *
27
+ * @public
28
+ * @param {boolean} visible visible flag
29
+ * @returns {boolean} true when visibility changed
30
+ */
31
+ ```
32
+
33
+ - Always state visibility explicitly: `@public` for API surface, `@private` for internals.
34
+ - `@param {Type} name description` — type in braces, lowercase primitives (`boolean`, `number`, `string`), `Object` for plain objects; document every parameter including defaults.
35
+ - `@returns {Type} description` whenever the method returns a value.
36
+ - Mark superseded API with `@deprecated` instead of deleting the comment.
37
+ - Name internal helpers with a leading underscore (`_getLineTexture`) — they are excluded from docs even without `@private`.
38
+ - The `plugins/markdown` plugin is enabled, so Markdown is allowed in descriptions.
39
+
40
+ ## Class ownership — two styles
41
+
42
+ **Default-exported ES classes (preferred, new code):** the class-ownership plugin resolves `memberof`, scope, and longname automatically. Do **not** add `@memberof`, `@name`, or `@instance` to class-body methods; a description plus visibility/param/returns tags is enough. Document the class head with `@class`/`@constructor` and visibility:
43
+
44
+ ```js
45
+ /**
46
+ * Annotation class constructor.
47
+ *
48
+ * @constructor
49
+ * @private
50
+ */
51
+ class Annotation extends AnnotationBase { ... }
52
+ ```
53
+
54
+ **Legacy function-constructor classes (e.g., `Viewport3D` in `src/viewport3d.js`):** members assigned as `this.foo = function () {}` need the full explicit tag set, otherwise JSDoc treats them as globals:
55
+
56
+ ```js
57
+ /**
58
+ * Check if renderer is in dev mode.
59
+ *
60
+ * @returns {boolean} true if renderer is in dev mode
61
+ * @public
62
+ * @function
63
+ * @name Viewport3D#isDevMode
64
+ * @memberof Viewport3D
65
+ * @instance
66
+ */
67
+ ```
68
+
69
+ Use `Class#method` for instance members and `Class.method` for statics in `@name` and `{@link}` targets.
70
+
71
+ ## Links
72
+
73
+ Use `{@link Class#method}` / `{@link Class.staticMethod}` for cross-references. The markdown generator fails the build on link targets without a matching anchor, so link only to documented, non-private symbols.
74
+
75
+ ## Validation
76
+
77
+ - `npm run lint-doc` — fastest check; runs `jsdoc --explain` and fails on malformed comments. Run after any JSDoc change.
78
+ - `npm run build-docMd` — regenerates the Markdown API doc and enforces anchor/link integrity; run when adding, renaming, or removing public symbols.
79
+ - `npm run build-doc` (HTML), `build-docConf` (Confluence, needs Python), `build-docAll` — full outputs; only needed when publishing docs.
@@ -0,0 +1,37 @@
1
+ ---
2
+ description: "Use when changing moment-timezone usage, sun-position calculations, renderer dependency declarations, or their tests. Explains the test-only dependency and web-app injection requirement."
3
+ applyTo: "src/utils/momentTimezoneInjector.js, src/viewport3d.js, src/exports.js, test/**, package.json"
4
+ ---
5
+
6
+ # Moment-Timezone Integration
7
+
8
+ - `moment-timezone` is a renderer development dependency used by local tests. The Vitest browser setup provides it to tests through the `moment` and `MomentTZ` globals.
9
+ - Do not treat the renderer's development dependency or test setup as making `moment-timezone` available to consuming web applications. Keep it out of renderer production bundles unless the dependency strategy is intentionally changed.
10
+ - Web applications using features that require timezone data, such as `setSunPosition`, must provide `moment-timezone` themselves and inject it into the renderer with the exported `injectMomentTimezone` function before using those features.
11
+ - Consumers can provide the library through their own npm dependency, a CDN, or another application-managed mechanism. Existing applications that already expose a compatible `window.moment` can continue to use it.
12
+ - Use the exported `hasMomentTimezone` helper to check availability before injecting when needed:
13
+
14
+ ```javascript
15
+ import { injectMomentTimezone, hasMomentTimezone } from 'bimplus-renderer';
16
+ import moment from 'moment-timezone';
17
+
18
+ if (!hasMomentTimezone()) {
19
+ injectMomentTimezone(moment);
20
+ }
21
+
22
+ viewport3D.setSunPosition({
23
+ northDirection: 0,
24
+ year: 2024,
25
+ month: 6,
26
+ day: 21,
27
+ hours: 12,
28
+ minutes: 0,
29
+ timezone: 'Europe/Berlin',
30
+ latitude: 52.52,
31
+ longitude: 13.405,
32
+ showSky: true
33
+ });
34
+ ```
35
+
36
+ - Preserve the runtime availability check and its clear error when required timezone support has not been provided.
37
+ - When changing this integration, keep the local test setup and the consuming-application injection path consistent.
@@ -0,0 +1,99 @@
1
+ ---
2
+ description: "Use when adding, running, or debugging renderer Vitest browser tests, modelviewer IFC DDT, Playwright image comparisons, screenshot baselines, or named report images."
3
+ applyTo: "**/vitest.config.mjs, **/playwright.config.mjs, **/test/**/*.js, **/modelviewer-data-driven-tests/tests/**/*.js, **/modelviewer-data-driven-tests/playwright/**/*.js, **/modelviewer-data-driven-tests/playwright/**/*.mjs, **/modelviewer-data-driven-tests/playwright/**/*.html, **/package.json"
4
+ ---
5
+
6
+ # Renderer testing: Vitest and Playwright image comparison
7
+
8
+ Run commands from the renderer directory. Follow the existing configurations
9
+ and helpers; do not introduce another test runner or restore Karma/Jasmine.
10
+ See [README testing documentation](../../README.md#unit-testing) for setup and
11
+ the full command reference.
12
+
13
+ ## Keep the suites separate
14
+
15
+ - Use Vitest for renderer unit/performance tests and IFC geometry DDT.
16
+ Import test APIs from `vitest`. These tests run in real browsers using the
17
+ Playwright provider, not a simulated DOM.
18
+ - Use standalone Playwright Test for IFC image comparisons. Import its APIs
19
+ from `@playwright/test`; keep visual entry points as `*.spec.mjs` under
20
+ `modelviewer-data-driven-tests/playwright/`.
21
+ - Keep Node reporter regression tests as `*.test.mjs`, outside Playwright test
22
+ discovery. Run them with `node --test`.
23
+ - Keep browser execution serial to limit WebGL and model-loading memory use.
24
+ Do not change production rendering behavior to make a screenshot pass.
25
+
26
+ ## Vitest conventions
27
+
28
+ - Reuse `test/setup/vitestBrowser.setup.js` for renderer globals, custom
29
+ assertions, and the per-test `#vitest-fixture`.
30
+ - Reuse existing viewer/viewport helpers and dispose viewers and WebGL contexts.
31
+ - Preserve Vite shader handling, binary IFC/OBJ imports, WASM MIME handling,
32
+ `/data/` fixture routes, and Polly recording compatibility.
33
+ - Unit/performance commands start Polly; geometry DDT commands start the
34
+ sibling `simple-ddt-server`. Do not conflate geometry references in
35
+ `Results.db` with visual PNG baselines.
36
+ - Keep CI recording disabled: missing Polly recordings must fail rather than
37
+ silently request live services.
38
+
39
+ ## Visual comparison conventions
40
+
41
+ - Discover IFC files from the selected short or long dataset. Reuse the
42
+ viewer harness and the shared renderer Vite asset/shader configuration.
43
+ - Await IFC loading and camera setup before comparison. Keep diagnostic,
44
+ non-empty model, and WebGL context checks.
45
+ - Compare only `#viewport-container` using the fixed perspective view without
46
+ camera flight. Preserve fixed viewport/device scale and deterministic options.
47
+ - Use Playwright's stable screenshot comparison, not arbitrary sleeps.
48
+ Current settings are threshold `0.2`, zero pixels above that threshold,
49
+ and a 15-second screenshot timeout.
50
+ - Loading is covered by the separate 100-minute per-test timeout. A missing
51
+ snapshot is not a loading timeout; inspect the error before changing limits.
52
+ - Visual tests must not write geometry references to `Results.db`.
53
+
54
+ ## Baseline safety
55
+
56
+ - Normal runs must not create or replace baselines automatically.
57
+ - Create only missing Firefox baselines with
58
+ `npm run test-modelviewer-ddt-visual-init` or
59
+ `npm run test-modelviewer-ddt-visual-long-init`.
60
+ - Use `-- --update-snapshots` only for an intentional, reviewed visual change;
61
+ never update baselines merely to hide a regression.
62
+ - Preserve baseline separation by browser, dataset, and OS. Generate and
63
+ compare on the same OS/GPU environment; review PNG changes before committing.
64
+
65
+ ## Reports and filenames
66
+
67
+ - Keep HTML output in `playwright-report/`, comparison artifacts in
68
+ `test-results/modelviewer-visual/`, and visual JUnit output in
69
+ `test-results/playwright-modelviewer-visual.xml`.
70
+ - Keep Playwright's internal hashed files so the HTML image viewer works.
71
+ - The custom reporter exports only actual comparison images directly into
72
+ `playwright-report/data/named/`: no subfolders, `-actual` suffix, expected
73
+ images, diff images, or full-page failure screenshots.
74
+ - Use the matching expected attachment's baseline filename, including its
75
+ full long name. Never derive that name solely from the actual artifact:
76
+ Playwright may shorten it and insert a hash.
77
+ - The flat folder cannot distinguish identical names across browsers/retries.
78
+ The last result in report order wins; run one browser at a time when needed.
79
+ - Test naming changes against both short names and the long Allplan filename.
80
+
81
+ ## Targeted validation
82
+
83
+ ```sh
84
+ npm run test-firefox-headless
85
+ npm run test-chrome-headless
86
+ npm run test-modelviewer-ddt
87
+ npm run test-modelviewer-ddt-long
88
+ npm run test-modelviewer-ddt-visual -- --grep "BasicProject.ifc"
89
+ npm run test-modelviewer-ddt-visual-long -- --grep "AssemblyElement.ifc"
90
+ node --test modelviewer-data-driven-tests/playwright/namedImagesReporter.test.mjs
91
+ npm run eslint
92
+ ```
93
+
94
+ Select the smallest relevant suite/filter rather than running every command.
95
+ `npm test` runs Firefox with Istanbul coverage. Chromium visual projects are
96
+ available through `npx playwright test --project=chromium` and
97
+ `--project=chromium-long`. For comparison/reporting changes, verify a passing
98
+ comparison and a controlled mismatch, inspect the exact exported filenames,
99
+ and remove any temporary visual modification without updating baselines.