frozeman
A demo is nice but what about some tasks to automate the separation ?
A demo is a nice thing, but the user still needs to do himself allot of stuff and it seems there's allot of trial and error involved.
What about some (Grunt) tasks to achieve what you described in an automated way?
Or some NPM package with extra commands to wrap around meteor commands/actions to ensure separation?
E.g. mfrontend create could wrap and call % meteor create and do the required stuff required to ensure it's separated.
On the same principle, e.g. mfrontend add srv-packages would emit a warning that it's not good for the client side, etc.
good idea. but i would prefer if the meteor core team would build this in natively.
what kind of extra trail and error do you mean?
but i would prefer if the meteor core team would build this in natively.
me too, but considering the entire history of the project, their roadmap and approach, I can pretty sure say that it won't happen, not in the next 3 years or so.
what kind of extra trail and error do you mean?
I mean to catch those meteor commands that would generate/do things on the server side too, since they are not necessary - only confusing or counter productive: e.g. adding packages that are server-side only (since this is a Frontend project) is only one example.
probably youre right. any experience with writing npm packages of this kind?
any experience with writing npm packages of this kind?
No :( .
Meteorite https://github.com/oortcloud/meteorite however could be a good example since it wraps or delegates most meteor commands.
Extending Meteorite with this kind of functionality however wouldn't be easy since the code of meteorite looks quite a mess to me and it's totally broken on Windows (even meteor kinda works there :) ).