I have completed the Discover Meteor application and I have a question related to the behind-the-scene performance of loading a package. To be more precise, the tutorial makes the user first creating the error handling functionalities inside the main meteor project and then makes the code modular creating an error package.
Beside the obvious advantage of having a package, is there a specific why one should create a package instead of simply having the same in the project? Any performance difference, any advantage on the way packages are loaded? Any disadvantage I should be aware of?
I can boil down the question in, does a package have better performances compared to the same code in the main project folder?
Creating a package doesn't inherently give you a performance benefit - the code is minified and inserted into the same bundle with the rest of your application. The primary advantages are:
As you pointed out, it makes the code reusable. Even if it's only a local package you can still use it between your own projects. Alternatively, if it's something you can share with others, you can publish it on atmosphere and let the rest of the community benefit.
You get a lot more control over the load order of dependencies and files within your application. Some members of the community have taken this idea to extremes by building their whole app using packages as seen here and here.
You can use tinytest.
I can't think of any obvious disadvantages other than the cognitive overhead of writing and maintaining the package.js file (it lists the dependencies, file load order, etc.). Also note that work on the package system is on the roadmap for 1.0, so be aware that some aspects will change in the coming months.
At work, we like to factor independent tools (like text generators and libs interacting with our mail provider), into packages even if they don't get reused across applications because:
It makes our app codebase smaller.
It keeps the git histories separate.
It helps enforce a clear separation of concerns.
This probably isn't an exhaustive list, but it should give you some ideas about the motivations behind package creation and use.