My app is pretty large though, trying to change to use this imports thing… seems no working so nice as I need to import even all sub-templates(html). So I am kind off interested in asking,is staying on 1.3 with the old file load system risky, or just remain on 1.2.
MDG has gone to great lengths to make sure apps using eager evaluation will still work with 1.3. Actually, it’s still the default behavior. You shouldn’t have any problems upgrading to 1.3 and continuing to use things are you were previously (with a few exceptions - see Migrating to Meteor 1.3 in the Guide). I wouldn’t recommend staying with 1.2 as eventually you’ll need to upgrade, otherwise you’ll continue to become more and more out of date (and miss out on new functionality, bug patches, security fixes, etc.).
All of that being said, MDG might decide to remove eager loading in the future. They haven’t stated clear plans to do this yet though (and I’m sure will be receptive to community feedback on this). For an in-depth discussion about all of this, check out:
Thanks Man, great reply. Do you use the Module System in full?
Yes and no - I’m working on a handful of different apps for clients, all of which are in different states (production/maintenance, active development, design phase only, etc.). Half are using ES2015 modules, the other half are not. A couple apps haven’t been updated to 1.3 yet as I have to wait for approval, maintenance windows, stars to align, etc. 1.3 is an awesome leap forward though (in so many areas), so I’m sure the rest will be updated to 1.3 soon.
1 Like
@hwillson Just a minor correction, MDG did make a somewhat a clear statement on it in the Meteor guide.
[quote]We expect a future release of Meteor will turn on modules by default for
all code, because this is more aligned with how developers in the wider
JavaScript community write their code.[/quote]
I personally hope they reconsider this, I’d rather not have to worry about imports for the Meteor API in smaller/medium sized projects that don’t need it, and I’m worried about the sheer inconvenience of upgrading larger projects to this format. I’m going to take advantage of the backwards compatibility as long as possible.
But we will have to wait and see how it turns out!
1 Like
What about 3rd-party files. eg I imported socket.io client file. but the main global variable isn’t still available. whereas 1.2 just included it in client/lib. But when I include it from their CDN. it works.
I also don’t think that MDG has said they would be completely eliminating the ability to NOT use ES6 imports either. I could see, this is just my guess, that they could still support the build tool with ability to use the older eager default loading through an environment variable and/or meteor built tool flag, if there is enough demand.
In the post you are replying to, I quoted comments from MDG stating they will turn on modules by default. It may not be clear, but modules are the name for the importing system.
This specifically means if modules are on by default, having to use the ES6 imports becomes a requirement, and the auto import/eager loading functionality would be removed, since imports are now a requirement.
They have not said anything otherwise, and have only said that they will enforce modules in order to fit in with the rest of the js community. But that does not feel right to me, as that was not ever the Meteor way.
It seems like Meteor is giving up their principals it was built on to fit in with the rest of the js community, rather than taking js and integrating it in the Meteor way like they always have in the past. More than other frameworks/platforms I have used, there was always a heavy emphasis on “the Meteor way”. I don’t want to give up “the Meteor way” for “the Javascript way”. There was a reason I chose Meteor for my javascript platform, and that reason was “the Meteor way”.
I can’t speak for MDG, but based on their past history in providing backwards compatibility, and the fact that it would break thousands of apps, I can’t imaging they would make the Meteor build tool ONLY support modules and lazy evaluation, at least into the foreseeable future.
Instead I would expect, and hope, that they turn on “modules only” support incrementally. For instance, in a Meteor 1.4 release they could offer an environment variable and build flag for the build tool that would turn on a modules only build structure with only lazy evaluation in you app. However, the default build rules would be just as it is in 1.3 with eager loading and lazy loading from imports/ and node_modules only.
At some later date, maybe a 2.0 release and when all of Meteor has been moved to NPM, they could make the modules only app structure the default for the build tool, but still offer an environment variable and build flag for the build tool to make it work in the “Meteor 1.3 way”.
In any case, it would be a huge mistake for MDG to not provide this backwards compatibility and a well thought out transition strategy. Of course, this is all just my speculation until someone from MDG pipes in here.
Yes sir, that’s why I’m so alarmed by these potential changes. It doesn’t match with their past history. But they straight up said “turn it on by default for all code”. It’s definitely unlike them, and I hope they do not go that direction.
It seems like it would be problematic for both smaller-mid size and larger projects. Smaller-mid likely don’t need the module functionality and won’t see any real gains. Larger projects will have thousands of files/import lines to edit. And if the users don’t upgrade they won’t get any future functionality/security enhancements.
It actually makes sense for non-Meteor NPM packages to have to be imported. But to require importing for Meteor’s base functionality as well as all the templates? That’s a very big undertaking for large projects, and not all of them need that functionality. And really, it goes against 'The Meteor Way" that we have spent so much time investing in.
1 Like