This is a Sass build plugin for Meteor. It compiles SASS and SCSS files with Dart Sass. With few alterations, this is the same documentation as for fourseven:scss on which it is based. Check your development server console for wrong syntaxes or Sass deprecation messages and correct your code accordingly.
This was made by plugging in Dart Sass as the Sass processor replacing the old node-sass. Nothings else is changed.
Just remove your old processor and add this package and … looking forward to hearing about your errors :).
fourseven:scss had some outdated indications for the use of Autoprefixer. The recommendation of this package is to follow Meteor documentation for Autoprefixer.
I don’t believe publishing new packages was necessary since fourseven:scss is under control of Meteor Community Packages. I’m sure the changes would have been more than welcomed as PR’s to that repo.
I do respect your opinion and everyone is free to install any package as well as to uninstall.
Given the present context with Meteor in between versions, many packages need 2 different versions because internally they depend on older (Node 14) and newer (Node 16+) NPMs.
Now, since you volunteered, you can pull from one of these packages and push to the community package.
I can definitely feel the respect of my opinion just beaming from your message…
That being said my point and my interest here is to limit fragmentation and confusion. The issue of divergent node versions could have been solved by a version branch in the original package.
It’s fine though, I’m more than happy to volunteer some of my time to work on features for Packosphere to try to limit this type of confusion in the ecosystem.
I am not sure I understand the confusion or fragmentation you are referring to. For almost 8 years I thought Atmosphere was free to use, free to publish but it seems that I’ve been wrong all along.
I totally understand your motivation and need for another package management platform since Meteor seems to operate with half an employee and 0 managers.
I didn’t know who was the contact for Paco so great I can ask you now. Is the publication of alphas and betas intentional? These versions do not show on the other package manager.
Just a quick clarification for anyone reading this thread today:
The current, up-to-date and fully working Dart Sass solution is fourseven:scss v5.x.
It uses Dart Sass properly, follows Meteor’s build pipeline, and is actively maintained with Meteor 2.10+ and Meteor 3 compatibility in mind.
The activitree:scss / activitree:scss3 packages are effectively obsolete at this point.
They implement Dart Sass in a flawed and outdated way, diverge from Meteor best practices, and contain architectural issues that cause real-world problems (especially around imports, package resolution, and minification).
For new projects — and especially for Meteor 3 — fourseven:scss 5.0+ is the correct and recommended choice.
The activitree fork should no longer be considered a viable alternative.
@illusionfield Thank you so much for your hardwork on this. But given 3.4 @grubba does this mean any build package is obsolete? I’m not just talking about SCSS but also coffeescript etc. Are you guys going to deprecate those core packages too? @nachocodoner
Hi @illusionfield I see fourseven:scss has received a final release 2 weeks back.
activitree:scss was released 2 years ago at a time when, if you had a project with SCSS and the latest version of Meteor, you could not build a production bundle.
Your clarification comes a bit late since the package was already clarified (deprecated) 15 months ago.
If you are the maintainer of fourseven:scss please try to clarify your packages when their updates are needed. I mean you literally published a full version when all SCSS packages have become redundant due to RSpack .
And yes — I’m also very happy to finally see Rspack land in Meteor, it’s been long overdue.
Just for context:
I originally built this about 2 years ago for my own use. At that time there was no proper Dart Sass solution that worked reliably for production builds, and honestly it was never meant to be released publicly.
About a year ago I decided to clean it up, harden it, document it properly and share it with the community.
That obviously took longer than expected — life, work, polishing, testing… you know how it goes
So yeah, the turnaround time was a bit… relaxed.
But now it’s solid, documented, and aligned with where Meteor is today — with or without Rspack.
Not obsolete, and I think we won’t deprecate anything because we do not want to leave our current user base without support – if you can’t move to the modern build stack, because you are still in 2.x or you rely on nested imports, then you should have some support. We will try our best to continue updating and keeping these packages feature-compatible but I think we would like to focus more on making us more aligned with the broader JS environment
For example, I plan[1] updating our typescript skeleton to use TypeScript - Rspack, hopefully it will make it faster.
