Meteor 1.3 *early beta* now available

announce
81

The interface is primarily what I am concerned with. If it makes sense for the implementation to be built on webpack, awesome! However, @benjamn indicated challenges in using Webpack which seemed to frame it as an “all or nothing” sort of thing:

In short, the argument for reusing the output formats of Browserify or Webpack is only compelling if you’re already using those tools during your build process, in their entirety. Without that harmonious integration of tool and output format, designing a new output format from scratch becomes a lot more appealing.

from: https://github.com/meteor/meteor/pull/5475#issue-112427098

We already can do that, just not using packages corresponding to Webpack loaders. But I assume you’re talking about harnessing Webpack for its ecosystem of loaders in general. That’d be great. I’m just not sure it should be driving force of the whole operation though–code splitting should.

Either way, I think we’re in total agreement on this:

We could essentially generate the equivalent of all the webpack config files behind the scenes, and hide them from the end user–that seems to be the idea here. And we can use any interface we want to make it as natural as possible for Meteor users to configure. And ideally, there’s the easy version, intermediate version and advanced version (likely plain webpack.config.js files).

It does seem though that MDG would have to bite the bullet on their build tools being completely built on Webpack, and it does seem that @benjamn already avoided that route (for various reasons discussed in the above github link).

So a “thin forum post” and “fat Medium article” (or gist)?? Duly noted. If you check Crater, u’ll see there also was an even longer Medium article lol: https://medium.com/@faceyspacey/meteor-1-3-wishlist-for-es2015-module-support-npm-interface-f5b2b081d9d0#.nvwgjki58

2 Likes
82

I guess as long as it doesn’t break the import feature and usage of node_modules in the 1.3 beta specs I guess I am down with that :wink:

83

Yeah I think those are primary goals of the project so I’d expect it to work!

84

Ok then… on to my beta production :slight_smile: I guess the new validated-method also would have less breaking changes given that it already has some solid specs.

85

@gschmidt will MDG hire @faceyspacey already? I like his ideas on code splitting and we need this as soon as possible.

6 Likes
86

I hope validated-method could be integrated with rate limiter, thus let us define a method in one place(and one object). Oh although its name already implies it won’t be like that.

2 Likes
87

Please don’t assume that the only use case for code splitting are different routes. The API should be agnostic for us to use in any situation.

5 Likes
88

How add local npm packages?

I just want test the package based project architecture like Telescope but I can not figure out how add local npm´s.

I do this:
1- First create a clean project.

meteor create Test-npm --release 1.3-modules-beta.0

2- Add node_modules: https://github.com/meteor/meteor/blob/release-1.3/packages/modules/README.md#local-node_modules

cd Test-npm

mkdir node_modules

First: Test with a remote npm:

1- # node install moment
2- add
client/client.js

import moment from 'moment';

console.log(moment().calendar());

This work like expected.

Second: Test with a local npm.
1- clone @arunoda npm-base to node_module: https://github.com/bySabi/npm-base
2- remove .git folder from npm-base
3- install it

npm install node_modules/npm-base

4- add
client/client.js

import sum from 'npm-base';
console.log(sum(1,2));

The last not work. Meteor output this error:

=> Started proxy.
=> Started MongoDB.

ReferenceError: dirPath is not defined
    at ImportScanner._tryToResolveImportedPath (/tools/isobuild/import-scanner.js:273:27)
    at /tools/isobuild/import-scanner.js:96:36
    at Array.forEach (native)
    at Function._.each._.forEach (/Users/flx/.meteor/packages/meteor-tool/.1.1.11-modules.0.106x9vk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at ImportScanner._scanDeps (/tools/isobuild/import-scanner.js:95:5)
    at /tools/isobuild/import-scanner.js:68:24
...
1 Like
89

Early Beta? I thought that was called Alpha right? No but seriously is this the version where current Blaze implementation will be replaced? What about SQL? Should I implement community SQL packages or expect something from the core. These are the features that I need in order to port real commercial projects from Rails.

Also note that things are happening in the other side of the fence as well. Rails 5 is coming out with build in Action Cable (websocket support), Turbolinks 3 (enable you to define partial page reloads instead of loading all), Rails API for SPA’s in core Rails and ruby < 2.2.1 for execution speed.

I think Rails 5 is heavily influenced what is happening in nodejs land and with meteor project.

1 Like
90

bysabi, the dirPath error is fixed here : https://github.com/meteor/meteor/commit/fb73d9e3704556018310b7c873b4e7a95fac807c, but a new error come’s up. see te end of there https://github.com/meteor/meteor/issues/5828.

1 Like
91

It could be nice if you could give us a new beta release after a sever bug resolution. It could also reduce issues.
Think’s a lot, I was looking for what you’re doing for a while.

92

We’ll get another beta release out today.

5 Likes
93

‘a new beta’ … good to hear it!

Now I try to convert a package full of Blaze templates to api.mainModule aproach but I can´t figure out how import / export a Blaze template.

anyone? @tjmonsi @avital?

94

Make sure your package has api.use("templating"), and try putting import "./the-template.html" in the main module? While I hope that works, it’s worth mentioning that this is somewhat uncharted territory, so any feedback you have about working with templates in modules will be much appreciated!

95

New release!

To update to the latest beta release, run the following command in your meteor project:

meteor update --release 1.3-modules-beta.1

Changes: https://github.com/meteor/meteor/issues/5788#issuecomment-165935104

9 Likes
96

@benjamn I was just wondering if you have any new info regarding lazy loading on new meteor apps? I’m getting ready to record a screencast on migrating a Meteor 1.2 app to 1.3 and that would factor into it a bit.

3 Likes
97

In an app, in the case of aurelia, we need to import an npm module as follow :

<body>
  <script>
    System.import('aurelia-bootstrapper');
  </script>
</body>

but aurelia-bootstrapper doesn’t exist in the source browser as we can’t import it from a js file.

98

@benjamn, as indicated in the release notes, Meteor 1.3 will introduce Ecmascript async and await keywords. Since Meteor used fibers to runs asynchronous code in a synchronous style until now, I wonder if these two strategies will co-exist for some time, and if the new keywords will be recommended over usage of fibers (I‘m also not quite sure of the consequences of this series of commits but I guess that’s related). Concretely will we have to insert a await keyword in these kind of statements:

let doc = Docs.find(docId);

?

6 Likes
99

@benjamn

How do we find which commit on GitHub 1.3-modules-beta.1 is made from? EDIT: After cloning, I see the tag release/METEOR@1.3-modules-beta.1, but the strange thing is I don’t actually see this tag while in GitHub’s UI, which is where I was originally looking.

Now that users populate node_modules themselves, are there any implications of using NPM v2 vs v3?

100

meteor update --release 1.3-modules-beta.1

does this include the speedups to load time that was in the previous

METEOR@1.2.2-faster-rebuilds.0

I’d prefer to keep fast builds as #1 priority…

1 Like