We’re trying something a bit different with this release. Instead of waiting until we have a feature-complete Release Candidate, we decided to err on the side of getting the release out sooner, even though it’s still under active development.
The initial beta contains various changes that have been sitting on the devel branch since the last release, along with the first usable implementation of the new module system.
Please comment here if you have questions about how things are supposed to work. Comment on the GitHub issue about bugs that you find, or missing features that you need.
I’m curious, since I’m not too familiar with ES2015 stuff yet, if the module support should only concern us as package developers or is this also relevant/helpful if we want to manage load order in general? Like for example, let’s say I can define if I want a package to load at all unless we go to a certain route? Can we still define the entire load order of packages we haven’t written ourselfs but just installed?
I know you mentioned lazy eval might become the default. My opinion is that if you don’t make this the default now for new projects you’re going to exacerbate the problem that Meteor has with experienced JS devs. There’s the ‘JS way’ you’re used to and the ‘Meteor way’ that you have to re-learn.
It also does a disservice to the users when they try to use any other JavaScript tool (like a test runner) and wonder why their files are not executing like they’ve learned.
I def. think that upgraded projects should not have lazy eval by default but all new projects should.
Also will there be any way to add a config to set a relative path when you don’t include dots? For example in webpack or SystemJS you can do this:
import {alpha} from 'both/models/post'
instead of this: import {alpha} from '../../both/models/post'
Now is definitely the time to consider the possibility of making lazy evaluation the default behavior (i.e., before Meteor 1.3 is officially released).
Besides the backwards compatibility question, my one hesitation is that, if all modules were lazy by default, there would have to be a way to specify the main entry point module, or a file naming convention that made certain files be eagerly evaluated. Do you have any thoughts or recommendations about that?
Also will there be any way to add a config to set a relative path when you don’t include dots?
For the time being, import statements are compiled to require calls, so my inclination is to continue interpreting module identifiers the same way Node/CommonJS does: https://nodejs.org/api/modules.html#modules_all_together. Specifically, a module identifier is never relative unless it begins with a ./ or ../.
As of this release, import statements can help with controlling load order within a single package or application, and they can help with importing properties from specific packages, but the loading sequence of packages is still determined by .meteor/packages and the api.use statements in package.js files.
There might be a future version of Meteor that requires you to import a package before it can do anything, which would give import statements more control over the load order of packages. For 1.3, loading packages automatically (in the same order they’ve always loaded) makes sense because there are a number of packages (ddp, accounts-base, others) that really need to load at startup in order to set things up.
Yea this is def. a tough one. In the context of Meteor I think that having a client/main.js and a server/main.js makes the most sense. I think most people like to structure their code in client/server/both folders and having a main.js in each might be the easiest.
Personally I use rather flat hierarchy to optimize ‘isomorphic’ use. I have main.client.js and main.server.js in the root like this:
Either way, if the default start app has code on the server and client executing it should be fairly easy to figure out (with copious comments for 1.3).
If Meteor is serious about isomorphic/universal JS then this pattern makes the most sense. If you want users to think about Meteor as a client and server with some bits shared, then having main.js in both client/server makes more sense.
For the time being, import statements are compiled to require calls
Does it mean we can take advantage of the new module system in Meteor 1.3 without ES6? For now, whenever Meteor learnt new tricks, they were accessible with CoffeeScript. Will it stay this way?
Add ‘Did you mean?’ reminders for some CLI commands to help Rails developers. #5593
Shots fired haha.
Don’t always download a new version of a Cordova app when it is first run.
I don’t get this one. Does it mean that the app will now download a new version on every first run or will it sometimes keep the old version on first run?
This is a fix for a bug that meant a Cordova app would always download a new version on first run, even if nothing had actually changed. See this commit for more details.
So using this new system rather than browserify would be great, but how can we ensure that included NPM packages reuse existing modules (such as React) rather than duplicating the code?
I’m confused about what will happen when we don’t use the relative syntax.
In the doc you gave an example of importing a package by NOT using a relative syntax. So what is your search order in that case (given that you have to search packages and node modules…) ?
I am still finding it hard to understand how to use import / export when it comes to adding blaze templating system. Or like adding routing files (I use FlowRouter)… what I usually do is I add these in this order:
var client = [
"client/template/main.html", // <template name="Main"> ... </template>
"client/template/main.js", // Template.Main.helpers, onCreated, onRendered, events
"client/template/main.css",
"client/template/route.js", // Here is where I put my FlowRouter route
]
api.addFiles(client, "client")
I don’t understand what lazy mean.
You are saying that the current execution of code in the beta is not lazy, which means it’s somewhat independant of the point in code where it’s actually imported. Is that correct ? Does that mean that “legacy” meteor load order still apply ?
Is it compliant with the standard ?
Next in the doc, you are mentionning :
Sometimes a module doesn’t actually need to import anything from
another module, but you still want to be sure the other module gets
evaluated first. In such situations, you can use an even simpler import syntax:
// c.js
import “./a”;
console.log(“in c.js”);
But for this to work, shouldn’t it need lazy (on import) evaluation ?
@benjamn really like the approach. Congratulations
I love the built-in support of NPM packages for both the server and client without wrappers. I think that’s a big step forward and it should really be this way. Wrapping the whole NPM just to import libraries felt so wrong.
My only concern with this new system is that I think this the perfect moment to think about Meteor’s bundling and lazy loading capability, another feature professional apps need when they grow, and Meteor is lacking right now.
I know this bundling issue is complex (and I really dislike the webpack syntax) but I think you should at least have it in mind while designing how the imports should work in Meteor. Maybe not to include it right now, but when you do, modules are ready and make sense.
Imagine how powerful it would be to serve:
a vendors.js with Meteor code base and most of your meteor and npm packages.
a common.js with the common logic of your app, dashboard, cordova, landing, etc.
a dashboard.js with the dashboard code for those who visit /dashboard.
a app.js with the app code for those who use your app.
a mobile.js with the code for those who use the cordova version of the app.
and so on…
vendors.js would be updated once each 2/3 months, common.js once in a while and daily changes will go to the dashboard.js, app.js and mobile.js bundles.
Meteor is not just front-end so we will rid of the simple front-end packages (or/and also simple independed backend packages) those could be on Npm, but we might still want to create Meteor specific packages which will use Meteor parts. So Atmosphere might be cleaner and better too.
Ps. I think that when we run ‘npm install some-package’ in the project for the first time the ‘node_modules’ folder should be created, now I need to createnode_modules by hand. This is a little bit unintuitive Npm don’t work like that
Npm don’t work like that