#V12 Compatibility Removals

1 messages · Page 1 of 1 (latest)

novel pivot
#

Threaded for discussion.

deep condor
#

the typescript lib is still not updated to include foundry.abstract.DataModel, correct?

manic mortar
#

Yeah it isn't.

agile jetty
#

Typescript stuff was never maintained by staff

manic mortar
#

Yeah, it isn't a part of the Core Foundry effort so it's probably off topic.

novel pivot
#

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.

gentle vault
#

It's less that TSDocs can help and more it's pushing the limits of Typescript it's self.

manic mortar
#

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

grizzled juniper
#

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

gentle vault
#

I've taken stabs at this as well. Headaches everywhere.

agile jetty
#

AFAIK it's all pretty wildly out of scope for this particular thread though

grizzled juniper
#

I will at least say I appreciate that it seems like we're through the worst of the basic document functionality changes

novel pivot
#

sort-of. Many of the compatibility removals do have to do with pulling away compatibility shims for the V10 data model.

grizzled juniper
#

Everything removed here is stuff that spawned deprecation warnings in console, right?

grizzled juniper
#

this seems like it should be like v11 where the worst breaks are anything you hadn't already fixed, rather than sudden breaks

novel pivot
#

I will say that the PR was really satisfying:

manic mortar
#

Lol those kinds of PRs ARE very satisfying

grizzled juniper
#

With v12 prototype 1 coming in December hopefully, does that mean the team is targeting mid-late spring for stable?

agile jetty
#

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

novel pivot
#

although we are nowhere near setting an official date on that.

grizzled juniper
#

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

agile jetty
grizzled juniper
#

v11 had a full 5 months from prototype 1 to stable

#

end of march would be 4

novel pivot
#

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.

agile jetty
#

Ah. IMO there's a lot more to a dev cycle than just starting at Prototype 1. The dev cycle starts months before that

novel pivot
#

we want fewer changes happening after the prototype phase.

grizzled juniper
manic marlin
#

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.

mighty rose
#

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)

agile jetty
mighty rose
agile jetty
#

Yeah, that just happens to be where ShapeData exists in the global namespace; it's not directly in globalThis

mighty rose
#

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){...
agile jetty
mighty rose
#

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.