I’ve copied this over to an issue on GitHub, so please post future comments there
Almost a year ago, @zoltan mentioned at a Meteor night that a future release might get rid of globals, which also get rid of the need for an imports/ directory.
Is this still the plan?
I bring it up now because recently the focus has been on features surrounding the build process (mostly to improve performance, but still a valid concern).
I understand that this would be a huge breaking change, but I think it’s time. Developers have had plenty of time to switch over to using imports, and it’s recommended by the tutorials and the guide. If developers don’t want to use imports, they can stay at whatever version still has globals. Having automatic globals can also pose security risks as well.
Since this is a big change, one possible in between step might be to have a globals/ directory. Then you put all files with globals in there, and everything else needs to be imported. This would essentially be the reverse of what we have now. (I do apologize if this isn’t actually feasible or if it’s extremely difficult. I don’t know enough about how the build process works)
A globals package that provides the currently shipped globals would probably work better than a directory. Add it next to insecure and autoimport as a prototyping package that can be removed when a project gets to a certain level of complexity. Plus it maintains backwards compatibility.
If globals are out, how will the basic structure of an application look like? How will Meteor know which file to start with that provides imports for client and server, if client and server folders won’t be global either?
Can you provide an MVP like the click counter example?
Will that mean that not only old applications using globals but also new applications using imports folder will have to be rewritten?
I was very vocal against imports, partly because we value speedy development, but also because imports didn’t make much sense for our project. I discussed this with management and the decision was made to hold off as long as possible on spending any dev time on imports.
Now with code splitting, there will be actual incentive for using imports. I have faith that in the future, the next meeting with management will go better regarding imports, now that there will be a measurable advantage.
I don’t think anybody is proposing to make people rewrite anything, just a way of making the whole app work like the imports folder if you want to do that.
It’s nice to encourage best practices… not force them. For small / individual teams, taking all the magic out becomes very painful and eliminates the primary decision to use Meteor in the first place.
I would think with some many lean competitors out there glueing together sets of similar but slightly different packages, MDG would prefer to keep as many developers as possible, and also lower the barrier of entry for noobs rather than raise it.
Also, re: following the Meteor guide… I have provided much support to new developers who screw everything all up because the guide is targetting production level teams with experience. It also heavily pushes people into using non-MDG packages (more prone to breakage) instead of learning how to do things the Meteor-way themselves. More pushing people away… not that I mind, more support $ for me.
I also took my time to learn most of the inner workings of Meteor in the pre-and-early 1.x phase and therefore able to take in the changes as they occurred.
Oh, one more re:… globals. What’s the big diff between including Meteor, Blaze (still the best), Templates, etc… everywhere (so they’re global… but not) and just letting Meteor magic happen? If the Template object is exploitable, not providing a global for it is not going to make it any more secure, lol.
@iDoMeteor, from my perspective, the globals topic is more about performance and clarity.
Having explicit imports means that:
Meteor can determine what modules are actually being used and only include those files, thereby potentially reducing build times and definitely reducing load times
Developers can determine what modules are actually being used in a particular file, so you don’t have to worry about setting a global variable in 2 places and unintentionally overwriting it
Development environments can determine what modules are being used in a file and provide auto-complete, advanced code checking, and easy navigation between files
The way things are today can be annoying for someone who has completely bought in to using imports, because they have to structure their application a bit oddly (use of imports folders) to take full advantage of the import functionality. This also means adapting non-Meteor samples to Meteor is more of a pain since you have to update all the paths to use the imports folder.
Having the functionality depend on a globals package that is automatically included by meteor create would be great - people using the global method would be unaffected, but people who aren’t using it wouldn’t have to use the imports folder anymore. This fits with your opening line, “encourage best practices… not force them”.
I also think that using a “globals” package added by default ( like “autopublish” and “insecure” ) at project creation or when updating to a certain version through finished upgraders could be a smooth transition allowing existing users to use the same patterns and at the same time also give the option of removing it and let dynamic-imports do some “new” magic.
The proposed solution of ben (using main and browser section in package.json) to state the two entry points seems quite reasonable to me too and wouldn’t require much configuration.
The only problem that remains to solve is what strategy should be adopted with meteor packages, since it was mentioned that there must be some of them still on the global level (like meteor Promise), thus packages should specify if they are eagerly evaluated or waiting to be imported. Such feature already exists (lazyLoad: true on api.mainModule), but most packages haven’t been updated to follow this design strategy (packages should be imported manually and we couldn’t use exported variables) and it remains to be seen if making people change is worth the time, knowing that an eventual npm transition is the last step of meteor packages.
Again, I think than current behaviour should be kept with the “globals” package present, but would be nice to remove eagerly loading from all packages without it. So if there are global variables needed (like Promise), meteor could declare them at startup individually, and make anything else load lazyly. Just my 2 cents
