Cross-OS Package Friction


I wonder what will happen as the number of Windows developers using Meteor overtakes those in the Mac and Linux community.

Will packages start to appear that do not work on the “traditional” Meteor stack? (Don’t think it’s likely to happen?).

At the moment I feel reasonably confident that most (recent) packages will work on all platforms without issue. Probably, all packages at the moment will work on Mac and Linux, because that’s where they were authored and their OS’s are fundamentally the same. However, I’ve already seen comments in which the phrase “doesn’t work on Windows” has appeared, and often in the context of packages.

Do you think it would be useful if package authors/users were able to “badge” packages with “Works on Windows”, “Works on Mac”, “Works on Linux”?

Do you think such a visible indicator would encourage cross-OS development and testing and so reduce usage friction?


It would be great if the set of commonly used packages worked on all platforms - the best case scenario is that there is no such thing as a “traditional” stack at all.

However, the reality is that some authors won’t take the time to make their packages work on all platforms, or maybe for some packages it doesn’t make sense (for example there might be something integrated with Linux system monitoring, or Windows registry, etc).

It would probably be good to have an easy way to determine which package work on which platforms, even if the main reason is so that we can promote cross-platform packages more. What do you think, @ekate?

Changing Package Metadata

At the moment I’m thinking of something along the lines of an optional package.js stanza with whitelisted properties having boolean true or false (or 1 or 0) values. A missing property would mean the compatibility is unknown:

serverPlatforms: {
  Windows: false, // Does NOT work on Windows
  Linux: true // Does work on Linux
} // There is no OSX property, so we don't know if it works on that

The onus is on the individual developer to do the tests and be honest. I had thought of a number of ways to make this significantly more complicated, but for an initial foray this seems sufficient. The object would be made available through the existing MDG Package API.

The three main server OS’s (Linux, Windows, OSX) would form the whitelisted properties. It does mean that if a developer gets a package working on AIX or z/OS I can’t indicate that, but I suspect they will be very rare, specialised cases.