I just looked on the new example todos app. All code is written in packages. To be hones, it’s not so easy read and navigate the code.
Why it’s recommended file structure for meteor apps?
1 Like
Manageable load order and ease of testing are two main reasons.
Also, packages can easily be shared among apps making it easier to reuse your codebase.
1 Like
Also, packages can easily be shared among apps making it easier to reuse your codebase.
I agree that if some functionality can be useful in other apps we can exclude it into package, bet whole app as set of packages, and most of that packages needed only for this app?
Manageable load order
Wouldn’t it be better to manage file order with import? We already have ways of using webpack in Meteor and as far as I understand in 1.3 import will be officially supported.
Also this todo app isn’t as big, so default Meteor way of file ordering should be totally enough.
I used to have file order problem in one quite big Meteor app, but still I prefer Webpack and imports. Putting everything into packages, having there additional package.js with configurations just makes code hard to navigate 
ease of testing
Could you elaborate on this?
most of that packages needed only for this app?
You may want to distribute your apps instances to specific tasks, like an admin and a frontend and a separate mobile client. Or you may want to try microservices. Having structured it with packages makes it very easy to do that.
Wouldn’t it be better to manage file order with import?
MDG is working on that for version 1.3 or possibly the one after that.
Also this todo app isn’t as big, so default Meteor way of file ordering should be totally enough.
The todo app is a scaled down example showcase of design patterns to what most largish meteor apps would require.
Could you elaborate on this [ease of testing]?
There is tiny test out of box which does package testing. Also, putting aside end to end and integration tests, packages that do strictly one job has known exports make it easy to do unit testing due to well defined boundaries.
Also, packages can easily be shared among apps making it easier to reuse your codebase.
A very good article on this. I’ve adopted the patterns recommended in the article and it works really well.
2 Likes
So from 1.3 this way of using packages for everything will be not recommended anymore?
@sashko, what are you going to recommend in in Meteor Guide? EC6 imports or putting everything into packages as best way of controlling file order?
Packages using import is also a thing. Then you could just do api.addFiles('_init.js') and never have to worry about fiddling about with your filenames in package.js.
The reason why package-oriented structure would not be obsolete because of import is that ultimately code is being shared through packages. So whenever you’re sharing code (even in your own app), the best approach is to stick it into a package. Packages also allow you to specify which other packages this piece of code depends on - making your code easier to test and manage.
1 Like
For 1.3: ES2015 imports. Packages are too awkward.
9 Likes
I agree 100%.
The packages approach is verbose and will be unwieldy at scale. Can’t wait for 1.3! If you need a solution today, using webpack isn’t too hard when starting from scratch.
3 Likes
@debergalis I have a few daunting questions about this.
Now that we are going the route of ES2015 imports and that packages are awkward:
- is atmosphere going to be obsolete (even though not immediately)
- is npm going to be the way forward
- if so, there was this talk about the version constraint resolver and the package system making sure builds are repeatable and that only one version of a package exists in an app whereas in the npm world, multiple versions of npm packages would coexist, complicating things up. => is this then still going to be the case with npm? how do we ensure repeatable builds and single-versions of packages?
4 Likes