Meteor 1.3 recomended app structure.

[v-anyukov]

Meteor guide, updated for fresh 1.3 version, recommends the following folder structure:
http://guide.meteor.com/structure.html#example-app-structure
Should we move mantra related code to the imports/client folder and leave only main.js in the client folder as client entry point?

[arunoda]

No. Mantra is build with Meteor 1.3 in mind. You don't need do that. Follow the architecture we've mentioned.

[chriswessels]

I think it would be better if Mantra used explicit importing (via the imports folder) instead of Meteor eager loading. Lazy loading (explicit) is far more in line with the rest of the JS ecosystem.

[arunoda]

@chriswessels Mantra uses explicit imports everywhere. client/main.js is the place everything is happening.
See: https://github.com/mantrajs/mantra-sample-blog-app/blob/master/client/main.js

[arunoda]

We use this because we need to place CSS files next to UI components. Earlier it was not possible to do that inside the imports directory. If that okay now, it's not a problem to use the imports directory. But, that directory looks pretty weird to me.

I think we need to come up with two things.

• Create a package where it create a single file entry point in Meteor. Meteor only loads client/main.js.
• Create a package to support CSS imports

This is the way how we can really fix this. What's currently in Meteor is suboptimal. imports directory will go away in Meteor 2.0.

For mantra, this is a not an issue at all. Even we write code in the client, we use explicit imports. If you want, just move your code to imports directory. But it doesn't do anything.

[tomitrescak]

👍 CSS imports are painfully missing in Meteor 1.3.

[natecox]

For what it's worth, from everything I've learned about the 1.3 architecture it would actually be in our benefit to support placing our modules inside of import directories since we're already importing inside the code anyways and it should speed up the app a bit to not eagerly load everything.

If we could solve the CSS issue I'd support using imports/ as a de facto implementation.

[merlinstardust]

The only reason to move our code under imports is if the code is eagerly loaded using the current implementation. So the questions to answers are

1. Is our code eagerly loaded, even though it is all explicitly imported?
2. Will MDG's recommended structure change in a future Meteor release?

This second question is because MDG is big on backwards compatibility so they would have only kept eager loading around to ease the transition from 1.2 to 1.3. At some point, Meteor will have a post 1.3 release that removes eager loading entirely, and it will most likely happen before or with 1.4. At which point, we'd need to move our app code back outside imports.

[fermuch]

It will surely by as you say, @merlinpatt, but I think another point is that Mantra should not depend on Meteor. If someone comes here without knowing the transition from Meteor 1.2 to 1.3, they would be shocked to see we have everything inside the folder imports without any good reason.

[natecox]

@merlinpatt I do not believe that the MDG is planning on removing eager loading entirely. The purpose of the imports/ syntax is for the developer to inform Meteor that the files within should not be eagerly loaded, exempting them from the standard rule of loading everything available. I haven't read anywhere that the default is going to change.

[v-anyukov]

about imports/ and css issue:
At this moment, I am using scss in the component folder and import it in the same way as JS modules (components -> module -> client/main.scss)

[kokjinsam]

by CSS Imports, are you guys saying importing css files in js files? In Meteor 1.3, you can simply import '/path/to/css/style.css in any js file.

[tomitrescak]

@sammkj are you sure that works? Asset loading and CSS loading is still on post 1.3 roadmap.

[kokjinsam]

I can confirm. you will have to put your stylesheets in the imports folder though.

[kokjinsam]

and actually this is already enabled during the betas. Lazy loading CSS modules.

Lazy CSS modules may now be imported by JS: 12c946ee651a93725f243f790c7919de3d445a19

in the history.md

[tomitrescak]

@sammkj so no loading CSS from NPM packages.

[EDIT] I'll give it a go later and confirm this.

[kokjinsam]

yea. that will be in 1.3.1. I wasn't sure if you guys are talking about lazy load css or loading npm css.

[jiku]

Lazy-loading through CSS processors is a bit hit and miss, but hopefully that too will make it into 1.3.1.

For ref, [Question] Why is imports directory not used? · Issue #39 · kadirahq/mantra

For now you could try (Meteor-)Webpack for both that and from NPM modules. See something like

Importing sass files from node_modules · Issue #121 · thereactivestack/meteor-webpack

[kctang]

By having things like "libs" directory that does not sit within "client" or "imports" directory, it is easy for server code to run eagerly - introducing multiple entry points to the app by accident.

For example, these collections are codes that run automatically on both server and client.

Using "imports" directory can avoid this.

[merlinstardust]

@natecox see Zoltan's quote here https://youtu.be/NICqNT-U4gk?t=1h11m58s regarding the future of the imports directory