Meteor 3.4.1 is out: Rspack consolidation, revitalized examples, and important fixes

announce releases
2
3

Meteor 3.4.1-rc.0 available. During this week we have been recieving the feedback on this version, and solving

  • Auto-detect branch and subdirectory in meteor create --from from GitHub, GitLab, and Bitbucket tree URLs, PR#14323
  • Delegate CSS processing to Rspack and switch to SCSS in the meteor create --full skeleton, PR#14324
  • Ensure Rspack child processes can find Meteor’s bundled Node, PR#14335
  • Disable Rspack HMR proxy in test mode to prevent WebSocket interference, PR#14329
  • Disable hot-module-replacement client WebSocket in test modes to stop __meteor__hmr__/websocket console errors, PR#14333
  • Improve existing examples by migrating to latest tools and improve styling, meteo/examples#PR42

During this week we will still accept feedback on critical issues in this version to be fixed. But by the end of the week we expect to publish the official Meteor 3.4.1.

6 Likes
4

Meteor 3.4.1-rc.1 available. We have landed the following changes in this new RC:

  • Update Blaze to v3.0.3 for SWC compatibility, speeding up the Blaze package build, PR#14354
  • Update docs and provide enhancements in the Service Worker and PWA support via the Workbox plugin in Rspack, with HMR and offline-refresh configs and simplifications, PR#14344
  • Enable .html imports on the Rspack server config for Blaze apps, PR#14350
  • Exclude the transient .cache directory from node_modules during bundling to prevent ENOENT race conditions, PR#14339
  • Upgrade all provided examples to 3.4.1-rc.1, ensuring test coverage remains verified and adding new features.
    • notes-offline got significant updates to provide a reliable offline config that works well with dev/HMR mode, autosync, etc.
    • notes-offline also showcases internationalization support using LinguiJS integrated into Rspack to automatically build i18n maps.
  • Deploy all versions of the examples app to Galaxy metal to ensure they deploy smoothly and are available online for everybody to check.

We had the chance to create a transient RC.1 version before the official release since we still owed the Blaze update for SWC. During this time, we also included other candidates for testing. The release cycle is now closed, and next comes the official Meteor 3.4.1 release.

2 Likes
6
7

I get this error when trying to update:

meteor update --release 3.4.1-rc.1
=> Errors while initializing project:

While selecting package versions:
error: No version of ecmascript-runtime-client satisfies all constraints: @=0.12.3, @~0.13.0-rc341.1
Constraints on package “ecmascript-runtime-client”:

  • ecmascript-runtime-client@=0.12.3 ← top level
  • ecmascript-runtime-client@~0.13.0-rc341.1 ← top level
  • ecmascript-runtime-client@0.12.2 ← ecmascript-runtime 0.8.3 ← babel-compiler 7.14.0-rc341.1 ← ecmascript 0.18.0-rc341.1
  • ecmascript-runtime-client@0.12.2 ← ecmascript-runtime 0.8.3 ← ecmascript 0.18.0-rc341.1
  • ecmascript-runtime-client@0.12.3 ← logging 1.3.6 ← email 3.1.2 ← accounts-password 3.2.3-rc341.1
  • ecmascript-runtime-client@0.12.3 ← logging 1.3.6 ← mongo 2.2.1-rc341.1
  • ecmascript-runtime-client@0.13.0-rc341.1 ← hot-module-replacement 0.6.0-rc341.1
8

Also maybe someone know what this issue could be about?

Uncaught Error: Cannot find module ‘@swc/helpers/_/_assert_this_initialized’
at w (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:5:1421)
at a.resolve (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:5:1545)
at a.s [as link] (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:7:5482)
at client-rspack.js (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:187:815974)
at g (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:5:2150)
at a.require (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:5:1674)
at e.require (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:7:4903)
at a.s [as link] (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:7:5567)
at client-meteor.js (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:187:815903)
at g (f23bc37d062939ce3d65e34e609c4e45381d3503.js?meteor_js_resource=true:5:2150)

This happens on andoid opera and samsung browsers only and on production only - tried a few fixes recommended by AIs but nothing worked. Could update to 3.4.1 help here?

9

Could you provide a bit more context on the version you want to upgrade from to Meteor 3.4.1?

Could you run a meteor reset beforehand?

Uncaught Error: Cannot find module '@swc/helpers/_/_assert_this_initialized'

This error may be related to a global cache problem. Maybe running npx meteor uninstall and then npx meteor could help with this.

Try these things, but it’s important to provide more context about the app you are working on: current version, whether you use local packages in ./packages/*, or METEOR_PACKAGE_DIRS with local packages.

10

That was it, thanks! I had it modified in local packages because of this issue: Issue · GitHub (it seems it should be solved now for 3.4.1?). Completely forgot about it :smiley:

@swc/helpers issue unfortunately is not resolved with 3.4.1… I do have this npm package installed but don’t know why it is not bundled in.

11

because of this issue: Issue · GitHub (it seems it should be solved now for 3.4.1?)

Yes, it was merged in Meteor 3.4.1, fix: displaying google maps in mobile application by mjcctech · Pull Request #13165 · meteor/meteor · GitHub

Could you verify is fixed?

Anyway, anybody using a local package forked with custom changes, they should get latest version and apply the patch with your changed. In your case, as it’s fixed probably, you don’t need that forked package anymore, but I say this to remind everybody that local forks need to also be in sync with latest changes.

@swc/helpers issue unfortunately is not resolved with 3.4.1… I do have this npm package installed but don’t know why it is not bundled in.

Does @swc/helpers described within dependencies at package.json? It should be described within dependencies, not devDependencies.

Did you try to completely clean you environment with meteor reset and reinstall meteor npx meteor uninstall and npx meteor?

12

Yes I removed that package and updated. I don’t get any issues so probably that issue is fixed now. I didn’t try reinstall meteor because that issue only happens in prod - I can’t reproduce it in dev.
I build with

meteor build --server-only …/new_package && mv …/new_package/*.tar.gz mypackage.tar.gz

And deploy with passenger.

13

Meteor 3.4.1 is out!

Meteor 3.4.1 continues the Rspack work started in 3.4. Cleaner logs, better CSS handling, swc.config.ts, service worker support in dev, portable builds, and more. It also improved docs, refreshed examples, Node 22.22.1, Blaze 3.0.3, and production fixes.

All the details you can find them on the article posted above.

5 Likes
15
16

Is anyone seeing this error:
"
Problems identified:

  1. reactRefreshModule is not a constructor - @rspack/plugin-react-refresh exports ReactRefreshRspackPlugin as a named export, not default. Fixed in app/node_modules/@meteorjs/rspack/rspack.config.js by using ?.ReactRefreshRspackPlugin.
  2. @rspack/dev-server missing - Installed with npm install -D @rspack/dev-server --legacy-peer-deps.
  3. Malformed meteor module exports - rspack generates invalid JS like module.exports = meteor/package:name; (missing quotes/require wrapper). Fixed with a preload script (patches/fs-patch.js) that intercepts fs.readFileSync and patches the output.

To run Meteor going forward:

./scripts/meteor-fix.sh
# or
NODE_OPTIONS="--require $(pwd)/patches/fs-patch.js" meteor

The root cause is a bug in rspack’s output generation for module identifiers containing colons. The fix should be reported to @meteorjs/rspack and @rspack/core.
"
when upgrading “@rspack/cli”: “1.7.11” and “@rspack/core”: “1.7.11” to 2+ ?

17

Yeah, definitely. I saw that in my quick attempt to update to Rspack 2.0.0, which we discussed here: https://forums.meteor.com/t/rspack-2-0-released/64576

This is not related to the Meteor 3.4.1 release. That release doesn’t verify Rspack 2.0.0 compatibility, since it’s a patch version and Rspack 2.0.0 came later with breaking changes.

Anyway, we are aware of the breaking changes in Rspack 2.0.0. It’s likely something we need to handle in the @meteorjs/rspack package, and maybe it can be patched there, though I’m not sure if it can be overridden through rspack.config.js direcly in your local projects.

I haven’t had time yet to dive more deeply into those failures, but I got the same errors you posted. I will do shortly.

18

News on Rspack 2.0 adoption today!

19 
meteor update --release 3.4.1

Meteor 3.4.1: unknown release.

I’m updating my Meteor app but got this error. Do you have any idea? Thanks.

20

Try these:

  • Force a catalog refresh: meteor --get-ready (or just run any meteor command in a project, it usually triggers a refresh, but sometimes it doesn’t).
  • If that still doesn’t see 3.4.1, make sure you don’t have METEOR_OFFLINE_CATALOG=1 set in your shell, that blocks fetching.
  • If not, nuke the catalog cache: rm -rf ~/.meteor/package-metadata and re-run meteor update --release 3.4.1. It’ll rebuild from the registry.
  • As a last resort, npx meteor uninstall and then npx meteor@3.4.1/npx meteor

Let me know how it goes.

21

Unable to update package catalog (are you offline?)

If you are using Meteor behind a proxy, set HTTP_PROXY and HTTPS_PROXY environment variables or see
this page for more details:
Using Meteor behind a proxy · meteor/meteor Wiki · GitHub

I don’t have METEOR_OFFLINE_CATALOG=1 set in shell

rm -rf ~/.meteor/package-metadata doesn’t help.

I have to manually install meteor version: curl https://install.meteor.com/\?release\=3.4.1 | sh

22

I see there is a bug now registered about this legacy bundle error. I pasted what AI identified as a problem after I analyzed the bundle itself, but I don’t know anything about js build systems so maybe it’s wrong. Maybe you can check it out, I left comment there.

23

This is great work! I am loving the new dev speed.

I am looking forward to restoring my client code back into Meteor’s control sometime (for now I compile it separately and place it in the meteor app using a separate step from Meteor, to avoid issues Meteor had with dependencies and basically to have full control in a simple way).

CSS has and is evolving a lot. I really don’t see SCSS being necessary as a default that requires learning a new language. CSS today has:

  • variables
  • nesting
  • functions and mixins
  • donut scopes with @scope
  • layers
  • native CSS Modules (import them into JS!)
  • if() logic
  • native scoping via ShadowDOM
  • plus more today
  • and more coming soon!

For browsers that don’t support the latest features yet, we can use PostCSS preset-env to compile new CSS to old CSS, and be aligned with modern standards.

Unless a CSS alt languages like SCSS or LESS provide a substantial benefit over native CSS, including making it worth new code deviating from standards evolution and the future debt that may add, and considering that CSS has caught up to the features of SCSS or LESS, I don’t see a big benefit defaulting to SCSS or LESS.

I really want to see a fully standards-aligned Meteor, with everything else optional to opt into.

2 Likes