#V12 Compatibility Removals
1 messages · Page 1 of 1 (latest)
the typescript lib is still not updated to include foundry.abstract.DataModel, correct?
Yeah it isn't.
Typescript stuff was never maintained by staff
Yeah, it isn't a part of the Core Foundry effort so it's probably off topic.
I don't know the status of the typescript community library, but if there are changes to the typedoc that DataModel uses that would make it easier for the typescript lib to provide typing support we are happy to investigate those changes.
Since we are using typedoc for our API docs, the ESModule where that class is defined does produce a valid .d.ts file, although it may not be as verbose as the community desires.
It's less that TSDocs can help and more it's pushing the limits of Typescript it's self.
As an author of a draft for DataModel it was quite possible to write an implementation.
The issue mostly lies in the fact that you get nasty infinite recursion issues
I was actually going to dig in this week to see if there's work I can do on the TS side of things since SWADE uses it
I've taken stabs at this as well. Headaches everywhere.
AFAIK it's all pretty wildly out of scope for this particular thread though
I will at least say I appreciate that it seems like we're through the worst of the basic document functionality changes
sort-of. Many of the compatibility removals do have to do with pulling away compatibility shims for the V10 data model.
Everything removed here is stuff that spawned deprecation warnings in console, right?
yes.
this seems like it should be like v11 where the worst breaks are anything you hadn't already fixed, rather than sudden breaks
I will say that the PR was really satisfying:
Lol those kinds of PRs ARE very satisfying
With v12 prototype 1 coming in December hopefully, does that mean the team is targeting mid-late spring for stable?
Looking through the list, TextEditor.enrichHTML moving to purely async is the only one I kinda might expect to hear a bit about in #system-development, though even then probably not much
I hope V12 will be stable by end of 2024 Q1
although we are nowhere near setting an official date on that.
Yeah, it's a far distance to predict. But good to know you're looking at a slightly faster dev cycle than the past two versions
Given that V11 came out this past May, IDK that that's accurate
It is an internal goal of ours to reduce the amount of time between Prototype 1 and stable, at the expense of taking longer and getting more features in P1 and P2.
Ah. IMO there's a lot more to a dev cycle than just starting at Prototype 1. The dev cycle starts months before that
we want fewer changes happening after the prototype phase.
it matters in the context of system dev planning because we're reacting after p1 drops
Ah, I only now realize I had missed a permission->ownership change, as an indirect consequence of the testUserPermission not having been renamed to testUserOwnership also.
Removed CONST.DRAWING_TYPES which was deprecated in v10 in favor of ShapeData.TYPES <- ShapeData.TYPES isn't a valid call, according to my installation. It tells me that ShapeData is not defined.
I use both CONST.DRAWING_TYPES and CONST.DRAWING_FILL_TYPES so need to fix that. (But I see DRAWING_FILL_TYPES remains a thing so that's not a problem)
foundry.data.ShapeData.TYPES is where it looks to be exposed
Ah, yes, that wasn't clear to me from the docs at all, as it just has it as a static attribute of ShapeData. But I see on looking again it does have it as under the data namespace.
Yeah, that just happens to be where ShapeData exists in the global namespace; it's not directly in globalThis
Regarding the deprecation of actor.token, does that still work if the object is actually a token? i.e.:
if (this.object.isToken){
if (this.actor.token.id == id){...
Why not drop the .actor.token part from there? That seems circuitous
It's part of a function that accepts a token id and only fires if the passed ID matches the actor currently being edited.
(Well, it accepts an actor ID)
I think the reported change doesn't affect my use case, as it says:
"Removed automatic migration of v9 Actor#token field which was deprecated in v10 and renamed to Actor#prototypeToken"
I think that's just getting rid of the old actor.token field, not the actor.token field you get on a token actor.
Yes this is correct