-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harmonize manifest pack names/filenames so we can use foundryvtt-cli
#781
Comments
foundryvtt-cli
foundryvtt-cli
I'm experimenting with migration strategies for this. Here's some notes. The FVTT const legacyLinkPointerPattern =
/@Compendium\[foundry-ironsworn\.[A-Za-z0-9-_]+?\.(?<id>[a-zA-Z0-9]{16})\]/g ...and then look for the captured const packIndices = game.packs.filter((pack) =>
pack.collection.startsWith(game.system.id + '.')).map(pack => pack.index)
return str.replaceAll(
legacyLinkPointerPattern,
(_match, _p1, _offset, _string, { id } ) => {
// search pack indices for entries keyed with the local id
for (const packIndex in packIndices) {
const indexEntry = packIndex.get(id)
if (indexEntry == null) continue
return `@UUID[${indexEntry.uuid}]`
}
}
) So long as the system's packs have already cached their indexes, this can be done synchronously; however,
Note that in a post-v10 world, any of these checks/migrations could be contingent on testing e.g. It's a little trickier to recursively iterate over all document string values, but I've figured out a couple ways to pull it off:
Both approaches can generate an array of document update deltas that are then passed to e.g. |
So we now have an automated build step that runs as part of |
foundryvtt-cli
isn't quite ready for use in a github workflow yet (it would need to support folders and ideally expose more of its API), but it's getting there.one problem i'd like to get ahead of: it expects the filename of a manifest
packs
entry to match itsname
. while this is explicitly stated in the API docs it hasn't really been a problem until now.so we're either going to need to rename a bunch of files (easy) or do migrations for account for the name change (harder).
i'd actually lean towards the latter, as i'll need to futz with a bunch of pack
name
s in the near feature, and it gives me an excuse to standardize the names 😉 . some examples:foe
actor tocharacter
actor drag behaviour to replace foe progress item packs #763i think i'd like to handle this by writing a custom migration method for
HTMLField
. it can look at a parent document's_documentStats
, and if it's below a certain system version, it can do the appropriate replacements.that'd probably be easier after migrating the rest of our custom subclasses to the v10 DataModel but that's already something i'm thinking about after #762. and, IIRC there's a way to flag for
HTMLField
intemplate.json
.The text was updated successfully, but these errors were encountered: