I'd like to remind that synclink stuff is nowhere published in the release so this task feels like ... let's just remove pyscriptjs folder and call it a day. We don't use anything from legacy code so synclink is not affecting by any mean the 2023 release to me, unless there's something else I am not considering.

Yeah. This is more about removing the old code (which includes old usage of synclink)

AFAIK this has been done so @madhur-tandon do you mind checking that box? ;-)

Done

what's the issue with display in workers?

also, about this:

to have feature-parity with classic

we want as much backward compatibility as possible but I think 1:1 feature-parity with classic should not even be a goal ... otherwise we should've just kept working on classic instead, right? We have new features, new patterns, new API, and that's the reason we're releasing PyScript Next ... not PyScript like before but also with other stuff ... the latter is a bit late in the pipe to me, not sure we're aligned in here.

Whether we strive for 1:1 feature-parity or not, that Epic is a good chance for us as a group to go through the features from Classic that are not-yet-implemented Next, and ask "Do we want to include this in a release, or not?" Even if each implementation not 100% identical, we can ask "Do we want error/warning banners? Do we want to reintroduce output and stderr as attributes? etc." on a case-by-case basis

sure thing, I didn't want to dismiss by any mean @antocuni work on this, he's been super helpful in general around various other topics too, I was just thinking if the goal for 2023 is to release py-terminal what's the purpose on spending time to understand if we want to test and fix everything else that's not a goal .. such as those attributes or everything literally else that could easily delay the 2023 release.

Do we want to focus on that? If that's the case, the punchlist becomes pretty meaningless to me, as there's way more to discuss and/or implement and/or fix, I hope this clarifies my previous message.

What I think I've been hearing so far from almost all maintainers is the same thing in different flavors. Basically, instead of "Fix all the remaining tests in the main thread" and "Fix all the remaining worker tests", I thought everyone mentioned something like: "Use the list of remaining tests and fix what we want to keep and track what we are intentionally removing". This is what I think @JeffersGlass and (maybe??) @WebReflection are saying here. I'm +1 on that as a way to build this punchlist and close.

Honestly, personally, I wouldn't like to go and re-create a massive list that will take another month for us to close.... I'd much rather build that list, pick what can solidify the release and small additional features (for instance, terminal if we can make it in time!) that can fit in a week time frame and aim to release next week.