Closed rsek closed 3 weeks ago
pattern
propertiesupdateMarkdownIdLinks()
updateId()
JSON.parse
current line of thinking: IDs will be restructured to {type}:${path}
, where path
is the package ID followed by one or more dictionary keys/indices separated by slashes. examples:
oracle_collection:starforged/core
(currently starforged/collections/oracle/core
)asset:starforged/companions/glowcat
(currently starforged/assets/companions/glowcat
)this groups all arbitrary path elements together, making globbing much simpler. for example, oracle_collection:**
can now match all oracles (currently, the same match is */collections/oracles/**/*
). it also makes globstars for non-recursive types more attractive, e.g. asset:**
, so i'll probably implement those.
embedded types will be standardized to {parentType}.{embeddedType}:${parentPath}.${embeddedPath}
. asset abilities may be folded in to this:
asset.ability:starforged/companions/glowcat.0
and asset moves an extension of that:
asset.ability.move:starforged/companions/glowcat.0.move_name
merged to v0.1.0
This should simplify composition and parsing of the IDs, and make it very clear what object type an ID belongs to (as the
type
ID fragment will always be 1:1 with the object'stype
value).examples:
starforged/oracle_collection/core
(currentlystarforged/collections/oracles/core
)starforged/asset/companions/glowcat
(currentlystarforged/assets/companions/glowcat
-- only changesassets
toasset
)Aside from rewriting the utilities that interact with IDs, some migration utilities should be provided. The simplest (and most portable) way to do this might be a set of regular expressions. Alternatively, they might be written in Haxe to see how well its cross-compilation holds up.