Basically, this Meteor package makes sharing code between client, server and mobile better by parsing and removing extraneous code for the server and client. This means code wrapped with if (Meteor.isServer) {...} won’t be served to the client or vice versa. The advantages of this is:
Smaller payload for the client, mobile and server
Better sercurity since wrapped server code won’t be exposed to the client
Slightly better performance due to reduction in extraneous code
Currently, filenames have to end with .isojs to use the package. I was kinda hoping Meteor would allow multiple source handlers in future so .js code can be parsed.
I thought that this was taken care of when deploying.
Never really looked into it but just assumed.
I don’t have too many places in my code where I have both client and server code separated in the same file. I feel like I try my hardest to keep server code in the /server directory.
edit:
Nice work on the package.
Sounds like something that should be used by default. Would there be any downsides in doing this on every project? Does it impact latency compensation?
Very good idea.
I had dreamt long ago of creating a new kind of Meteor Server-Client object, all in one file.
I think is very useful especially for collections (publications , subscriptions and utilities)
Kudos
Latency compensation should not be affected but using a meteor build plugin like this probably increases the build time. Most likely this would not be very noticeable unless there are a lot of files to be parsed.
A possible downside is decreased code readability when a function or method need to do a lot of stuff. On the other hand, it may be easier to maintain code in a single file compared to files in the server and client folder.