Keep in mind, current meteor-scss still uses node-sass - npm while Leo’s and activitree fork use Sass: Dart Sass which is an entirely different library.
@storyteller @harry97 I left some comments in the PR. But that’s mainly it, I am using a JavaScript-only implementation of SASS, and it’s also using it’s sync API which is also faster. The tests work fine in Meteor 3 and the package imports also seem to work fine in my fork. Hope it helps.
1 Like
FWIW I tried using Leo’s scss compiler in Meteor 2 but that failed… It only works in Meteor 3 for me.
Since the github project doesn’t have Issues enabled, I couldn’t file a bug report.
/Users/redacted/.meteor/packages/meteor-tool/.2.16.0.g8yvo.k9wfpt++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:75:12:
Cannot await without a Fiber
at awaitPromise
(/Users/redacted/.meteor/packages/meteor-tool/.2.16.0.g8yvo.k9wfpt++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:75:12)
at Promise.await
(/Users/redacted/.meteor/packages/meteor-tool/.2.16.0.g8yvo.k9wfpt++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:60:12)
at CssOutputResource.finalize (/tools/isobuild/compiler-plugin.js:930:12)
at CssOutputResource.hasPendingErrors (/tools/isobuild/compiler-plugin.js:935:10)
Crap I thought it should work in both, will have a look. I also enabled issues for it, thanks.
@permb I cannot repro, do you import any packages inside your .scss files? If you have any other info on how to repro would be great.
Has anybody been looking into lmieulet:meteor-coverage - Packosphere yet for Meteor 3.0? Or is there a replacement?
I will repro from source code early next week (away for the weekend) - I suspect it’s just a matter of wrapping the main callback sent to dart with a Meteor.bindEnvironment.
Great, enjoy your weekend! Thanks
OK so this should be made more visible in the documentation somewhere, or maybe even considered a bug:
Compilers that rely on the meteor caching-compiler package cannot be dual-published for Meteor 2 and 3.
The details are a bit hairy, but I learnt from zodern that when publishing a compiler plugin (isobuild), the package will include copies of processed (reify+babel) meteor dependencies that are then used instead of using code from the installed meteor version. This ONLY applies to build plugins.
The caching-compiler code as emitted when publishing for Meteor 3 is incompatible with Meteor 2 and vice versa.
1 Like
It would likely be possible to modify the code in the Meteor 3 version of caching-compiler to work in both Meteor 2 and 3 by removing all usages of the async and await keywords and use raw Promises instead since Promises in Meteor 2 are backed by fibers.
Apologies if this was covered, but what is the state of redis-oplog? Two quick notes:
-
I see it listed on row 53 on the original spreadsheet:
Meteor 3.0 Packages Compatibility - Google Sheets -
I also found a migration here: meteor-packages/redis-oplog at main · quavedev/meteor-packages · GitHub
I also feel like I read a post that it’s potentially going to be pulled into Meteor core?
Thanks for clarifying!
Seems to be a misunderstanding of which repository the package is using
I’ll be happy to merge PRs and publish new versions. I’m currently unable to contribute more than that.
As for it being pulled into core that is something being considered for Meteor 3.1 and discussion is ongoing. Most likely is going to happen, the bigger question is how to make that happen properly. There is also now DDP-router that can change the game a bit:
That sounded like a Galaxy thing. I hope Meteor is not going with 3.1 into the … Galaxy direction ending 2-3 years down the line like … Meteor Pro and Meteor Community.
Just wanted to point out that a new version of collection hooks got released thanks to the great efforts of Berislav Hunjadi / @bhunjadi .
5 Likes