I have this in my package.json:
"meteor": {
"modern": {
"transpiler": {
"verbose": false
}
}
},
Should I replace that with:
"meteor": {
"modern": true
}
Why 3.3.2? Not just straight into 3.4?
Meteor 3.3.2 will give us more room for fixes and regressions, as a straight release. Some issues were mistakenly introduced in 3.3.1, like
We have others that will be available in a faster release cycle.
Meteor 3.4 will require several betas; not sure how many. We haven’t had the first beta yet, so the time frame to an official/recommended 3.4 release is uncertain and likely longer. Keeping the 3.3.x series gives us time to introduce fixes and act on possible regressions or critical updates, while we prepare and deliver 3.4 betas in parallel.
Oh I see you’ll continue shipping bug fixes under 3.3.x while mainstream features that require multiple betas under 3.4 both in parallel
Sounds phenomenal, thank you and the core team for the efforts.
Awesome stuff! Praying for Capacitor and Electron integration (or an update to meteor-desktop) as I have apps that I haven’t been able to push updates to in years.
Hmm… if I set modern == true, I will lose the transpiler setting. Is there a new config option so as to keep both?
"meteor": {
"modern": true
}
With this configuration, you enable all improvements from the modern build stack in your Meteor app.
By default all Meteor Bundler optimziations are enabled with modern:true including transpiler, minifier, watcher and so on. You can only disable if you specifically set false to any of these, like “meteor.modern.transpiler=false”.
Would something like this be correct?
"meteor": {
"modern": true,
"modern.transpiler.verbose": false,
}
No, I wrote a simplification of the code. You can either do:
"meteor": {
"modern": true
}
or
"meteor": {
"modern": {
"transpiler": {
"verbose": false
}
}
}
Not praying as we’re running the latest ElectronJS version:
“electron”: “^37.2.6”,
without any problems. That being said, I know others have problems and the dependabot has listed a huge list of outdated versions that have many security problems on top of those that ElectronJS (including up to the previous version of 37.2.5) has.
If we switch to Capacitor or continue with ElectronJS, it doesn’t really matter much when the packages itself aren’t kept up-to-date and security risks are introduced.
but it only works on Meteor 2 right?
I recently got it running on 2.16, still having issues with build, hoping I can resolve that somehow
No, we’re on the latest Meteor version 3.3.1
Hmmm I just tried a fresh meteor create --blaze, then ran the setup steps from the repo, but was not able to get it to run. May be similar issue to this ticket.
ERROR electronApp: error while transpiling or minifying: TypeError: api.caller is not a function
That error isn’t stopping the app from working, see our log:
INFO electronApp: transpiling and uglifying
ERROR electronApp: error while transpiling or minifying: TypeError: api.caller is not a function
at builder (/Users/andreaswest/Documents/workspace/frontend/node_modules/@babel/preset-env/src/index.ts:398:13)
at /Users/andreaswest/Documents/workspace/frontend/node_modules/@babel/helper-plugin-utils/src/index.ts:62:12
at ElectronApp.transpileAndMinify (/Users/andreaswest/Documents/workspace/frontend/node_modules/@meteor-community/meteor-desktop/lib/electronApp.js:854:33)
at ElectronApp.build (/Users/andreaswest/Documents/workspace/frontend/node_modules/@meteor-community/meteor-desktop/lib/electronApp.js:451:24)
at MeteorDesktop.run (/Users/andreaswest/Documents/workspace/frontend/node_modules/@meteor-community/meteor-desktop/lib/index.js:123:9)
INFO electronApp: packing .desktop to asar
VERBOSE electronApp: clearing temporary .desktop
INFO meteorApp: checking for any mobile platform
INFO meteorApp: building meteor app
DEBUG meteorApp: clearing build dir
INFO meteorApp: acquiring index.html
INFO meteorApp: successfully downloaded index.html from running meteor app
VERBOSE meteorApp: copying mobile build
INFO meteorApp: acquiring manifest.json
INFO meteorApp: successfully downloaded manifest.json from running meteor app
INFO meteorApp: mobile build copied to electron app
DEBUG meteorApp: copy cordova.js to meteor build
INFO meteorApp: injecting isDesktop
INFO meteorApp: injected successfully
INFO meteorApp: packing meteor app to asar archive
VERBOSE meteorApp: clearing meteor app after packing
INFO meteorApp: meteor build finished
INFO electronApp: running
info: [main] app data dir is: /Users/andreaswest/Library/Application Support/yourDNA.family
info: [main] initial desktop version is 03ee0dd9296c61f01949334297dea47b6ef1c8a1_dev
info: [main] will use desktop.asar from initial version because the initial version of meteor app has changed: /Users/andreaswest/Documents/workspace/frontend/.meteor/desktop-build/desktop.asar
debug: [main] skeleton version 4.0.0-rc.0
Please note that we didn’t start with a fresh setup but rather converting our existing Meteor ElectronJS app to work with both Meteor 3.x and then also with the newest ElectronJS version.
well basically, it does not run on a fresh setup nor on Meteor 3 :\ effectively killing my old app haha. I would pay if someone could fix that package up and get it working reliably
If now all the latest versions are about bundling, then maybe add dynamic imports for cordova to the roadmap.
Now web.cordova build bundle all in one js file:
But for web.browser add dynamic imports:
For example my bundled js file size 23Mb:
But for web.browser 7.4Mb. Cordova app startup time for 23Mb is very long! Don’t get it why cordova don’t bundle dynamic import, while meteor cordova plugin run full http server to serve app assets.
This is one of the positive effects we expect from the upcoming Meteor-Rspack integration. Why? Dynamic imports in modern bundlers like Rspack output split code as files in the public folder, and that folder is included in the Cordova context. This lets a Cordova build preserve the main file and the split chunks from dynamic imports, so they load and run as expected in any browser-like context, as native Webview.
Adding Meteor’s DDP dynamic imports to Cordova, like other features modern bundlers already provide, would be duplicated work and research that may not be worth it or within our capacity. A better approach, given our means, is to embrace modern tools and standards, and then measure the impact soon.
I don’t think you need/want dynamic-import on Cordova because you have/want the entire client to be on the device, especially for low speed / offline use
Mb i don’t really understand how Meteor bundling work, but, what i see now: cordova-plugin-meteor-webapp run http server on mobile device, all app assets including public folder served locally from device (not from internet/meteor server). Only ddp and http requests that not in manifest.json go to internet.