mirror of
https://github.com/penpot/penpot.git
synced 2026-10-29 22:10:34 +00:00
7105f3038e
The migration 0032 stores every swap of a file as an override group. A swap made in a copy is paired with the child of the near main that holds the same position, as sync paired it; any other slot is dropped. All pairings are found on the data as it was, so swaps nested in swaps pair against the content of the outer one, and libraries pair the same whether they are migrated or not. A head that refers to its own slot only inherited it, and drops it even when its near main cannot be reached. Any other slot that matches no child, or whose near main is in a library that is not loaded, keeps the slot as its ref, so validation reports it. An import, which migrates its files before it links their libraries, leaves those slots and converts them once the libraries are linked. A migrated head that sits elsewhere than the child it replaces would place it gets its geometry marked as touched, so the first sync does not move it. Migrated and new files carry the feature components/swap-group, so a client that still writes slots cannot open them. Validation checks the new form: :misplaced-slot reports any slot, :misplaced-swap-group the group anywhere but on a nested copy head in a copy, :ref-not-in-near-main a nested copy head whose ref is not a child of the near main of its parent, and :duplicate-ref two children of a copy that refer to the same main shape. Each has a repair. Nothing but the migrations reads slots any more: the slot branches go from sync, swap, switch, reset, detach, paste, duplicate and move. The helpers that read and write a slot on a shape move to files/swap-slots, and the ones that follow refs to files/comp-processors. The graph projection drops the FillsSwapSlot edge, the components debugger shows the component a swapped head takes its content from, and the plugin API documents componentRefShape for a swapped copy. The swap tests are named after what they check. Benchmark (lower quantile, ms; baseline / now / ratio): deepest-edit-through-three-levels 35.2 / 34.6 / 0.98 edit-through-a-chain-of-dependents 68.9 / 63.5 / 0.92 library-update-into-copies 83.1 / 76.4 / 0.92 main-edit-into-10-copies 1.8 / 1.6 / 0.87 main-edit-into-100-copies 15.4 / 15.1 / 0.98 main-edit-into-1000-copies 153.1 / 148.8 / 0.97 variant-switch-into-copies 32.1 / 26.4 / 0.82 AI-assisted-by: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Penpot plugin-types
The @penpot/plugin-types package provides TypeScript type definitions for the Penpot Plugin API, making it easier to develop plugins for the Penpot design platform with full type safety and IDE support. It streamlines the development process by ensuring that your code is well-typed and less prone to errors.
Getting started
Installation
To add penpot's plugin-types to your project, use the following command:
npm install @penpot/plugin-types
Configuration
To ensure the typings work correctly in your project, update your tsconfig.json as follows:
"typeRoots": [
"./node_modules/@types",
"./node_modules/@penpot"
],
"types": ["plugin-types"],
Learn more
For more information on how to build plugins using the Penpot PLugin API, refer to the official documentation. You can also explore practical examples in the samples repository to see real-world implementations.