Since Meteor 1.3 officially supports NPM, I thought it would be better to install packages directly from NPM. But I don’t know how to run it on Meteor. Installing is not enough and Stylus documentation doesn’t say anything. How are this kind of packages run on Meteor? Meteor 1.3 does everything with import and export but I just couldn’t figure out how to apply that to Stylus.
Meteor has its own build system: http://guide.meteor.com/build-tool.html This is the place where you should plug in with your preprocessors, and there is an official stylus package for Meteor, so you just need to add it and write your .styl fles. If you want to write your own build plugin here is the api: https://github.com/meteor/meteor/wiki/Build-Plugins-API
Thanks a lot. This NPM support made things a little complicated for newbies.
By the way, a little bit unrelated but which preprocessor should a Meteor developer use?
Stylus or Scss?
Personal preference - they both work really well with Meteor. Sass is defintiely more popular (along with LESS), but I prefer working with Stylus due to its clean/minimal approach, in-language functions, and how it handles mixins.
yeah, personally I choose Stylus too, but unfortunatelly Sass and Less are more popular (imo not better ;)) so in many projects we need to work with Less or Sass.
So I’m guessing that you don’t depend on libraries much?
Which libraries forces you to use Sass/Less? If you have a list of your popular libraries for Sass or Stylus, could you share?
All major CSS frameworks (like Foundation or Bootstrap) works with Scss or Less. Also many ready to use projects (mockups, themes) includes .scss or .less files, this is why sometimes you just need to use other preprocessor than Stylus
When I work with stylus I use my own grid and some other stylus plugins, but the problem with Meteor is that you can’t add new Stylus plugins without writing your own Stylus package which will include Stylus build plugin. For example I have my own Meteor package which gives you Stylus build plugin with many other Stylus plugins like my grid, rupture or even possibility to use PostCSS with it. Standard Meteor package has only Stylus build plugin.
I use the mquandalle:stylus package, which bundles Stylus with several plugins together:
I came to Meteor because it seemed so easy to build things. But lately, I’m pretty bummed out due to package limitations. I thought NPM support would solve this problem but no, I’m still stuck with Atmosphere. I see you created many great packages but if you (or any other package owner) stop supporting it, that would ruin my app even though the original code itself (not Atmosphere package) is very well supported and grows everyday. I want my stuff future-proof but I still can’t figure out this styling problem.
Thanks for the list. How can you be sure that package will always be updated?
You can’t, but you also can’t be sure the MDG stylus package will be kept up to date either (which it isn’t). The good news is that it’s all open source! You can fork and update yourself, submit a PR back to the original project, or open an issue and hope someone else takes care of it.
That’s the problem I’m talking about. Instead of supporting the installing/using original source, Meteor package system forces you to write something unnecessary. So you end up working on Meteor packages instead of your own app.
Yes, using wrapper packages can be a bit of a pain for sure. That’s why MDG has brought in npm support, and when issue 6037 has been completed (it’s almost done now - looks like it will be in Meteor 1.3.2!), this will all get a bit easier.
Npm support will give you a way to use all front-end Npm tools but still, the build system in Meteor is really limited (imo). At least there should be a good documentation with examples how to build your own build package. Regarding Stylus in Meteor. They even have forked Stylus to be able to properly run it with Meteor. All preprocessors uses plugins system. And this is almost impossible to use with core Stylus or Less package. You need to write your own to be able to do that. I hope that Meteor build system will be simplified and more elastic asap. This is what I like in for example Webpack.
Yes, exactly! Documentation is very limited. They did good job with the new guide but it’s not enough at all.
But still, forcing people to wrap stuff to just make it work on Meteor is ridiculous. They should’ve fixed this long time ago. I understand Atmosphere is specific to Meteor but making incompatible with anything else is really weird. When the time required to bring NPM support considered, I’ve no hope to have these issues fixed really soon.
That’s good to hear!