Skip to content

Meteor 3 compatibility release#60

Open
StorytellerCZ wants to merge 13 commits into
masterfrom
feature/meteor3
Open

Meteor 3 compatibility release#60
StorytellerCZ wants to merge 13 commits into
masterfrom
feature/meteor3

Conversation

@StorytellerCZ
Copy link
Copy Markdown
Member

@StorytellerCZ StorytellerCZ commented Aug 19, 2024

Based on #59, this PR takes the next step and makes things compatible with Meteor 3.

TODOs left

@StorytellerCZ
Copy link
Copy Markdown
Member Author

I'm wondering if mtest is compatible with Meteor 3. I see no reason not to, but the cancellation is strange.

@wreiske
Copy link
Copy Markdown
Collaborator

wreiske commented Sep 12, 2024

Looking forward to this! I tried getting the latest versions of both running with Meteor 3.0.2 but ran into this...

meteor add mizzao:user-status@2.0.0-beta.0
mizzao:user-status with version constraint 2.0.0-beta.0 has already been added.

wreiske@Wills-MacBook-Pro bluehive-ai % meteor add mizzao:timesync@1.0.0-beta.0
 => Errors while adding packages:             
                                              
While selecting package versions:
error: Conflict: Constraint mizzao:timesync@0.5.4 is not satisfied by mizzao:timesync 1.0.0-beta.0.
Constraints on package "mizzao:timesync":
* mizzao:timesync@1.0.0-beta.0 <- top level
* mizzao:timesync@0.5.4 <- mizzao:user-status 2.0.0-beta.0

@StorytellerCZ
Copy link
Copy Markdown
Member Author

@wreiske I'll release a new rc for mizzao:user-status to fix this shortly.

@alisnic
Copy link
Copy Markdown

alisnic commented Jan 10, 2025

After upgrading to Meteor 3.0.4 and to timesync 1.0.0 beta, the _timeSync method is called very often:

Screenshot 2025-01-10 at 11 09 42

These are stats for 7 active containers on galaxy and about 700 connections

@StorytellerCZ
Copy link
Copy Markdown
Member Author

That is a concern, but at first look I don't see any change that should cause an increase. 🤔

@alisnic
Copy link
Copy Markdown

alisnic commented Apr 3, 2025

@StorytellerCZ my take is that timesync does not account that ddp methods are queued, and if timeSync calls are blocked by other method calls it will just re-issue timeSync calls. I think this whole DDP thing needs to be reverted

@jankapunkt
Copy link
Copy Markdown
Member

@StorytellerCZ this is blocking because mtest is not meteor 3 compatible

@jankapunkt
Copy link
Copy Markdown
Member

related zodern/mtest#2

@allenfuller
Copy link
Copy Markdown

Anything those of us in the community can do to help? Just updated to Meteor 3.4 and unable to update this package.

Newer versions of the following indirect dependencies are available:
 * mizzao:timesync 0.5.5 (0.6.0 is available) 

@jankapunkt
Copy link
Copy Markdown
Member

Hey @allenfuller I also found the update to 3.4 caused a lot of dependency issues. I think we need to bump core versions to include 3.4.

@jankapunkt
Copy link
Copy Markdown
Member

I published a new version 1.0.0-beta.1 which you can try to install. I also noticed the issue @alisnic reported is not really resolved which is why I will assign myself to this PR to make this work and publish the package.

@jankapunkt jankapunkt self-assigned this Feb 9, 2026
@jankapunkt
Copy link
Copy Markdown
Member

jankapunkt commented Mar 29, 2026

@StorytellerCZ I would like to move biome with this

harryadel and others added 5 commits April 16, 2026 17:26
Add two Mocha tests under a 'transport selection' describe block:

- forces DDP on Meteor.isCordova=true — asserts Meteor.callAsync('_timeSync')
  is used and globalThis.fetch to the sync URL is not. Reproduces the
  scenario that motivated the fix (Cordova client with useDDP still false).

- uses HTTP on a plain browser — guards the else fetch(...) branch of
  updateOffset() against accidental deletion, proving the fix does not
  regress the web.browser path.

Both tests install spies on Meteor.callAsync and globalThis.fetch, drive
a TimeSync.resync(), and poll with simplePoll rather than a fixed timeout
to stay reliable under CI load.
The previous fetch spy installed itself on globalThis.fetch, but
timesync-client.js imports fetch from meteor/fetch as a module binding
at load time. Replacing globalThis.fetch had no effect, so the browser
regression test could never observe an HTTP sync and timed out.

Switch to PerformanceObserver on 'resource' entries, which captures
any fetch() to /_timesync regardless of how the caller references it.
@harryadel
Copy link
Copy Markdown
Member

Published 1.0.0-beta.2 thanks to @BastienRodz contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants