Meteor 1.3 *early beta* now available

‘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?

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!

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

@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

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.

@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

@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?

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

Wow, just… wow. Great work @benjamn, exactly what the community needs right now :wink:

Yes, 1.3-modules-beta.1 contains the change in 1.2.2-faster-rebuilds.0

2 Likes

Has anyone managed to get redux-devtools working with 1.3?

I do:

npm install redux-devtools --save

then:

import { createDevTools } from 'redux-devtools';

but in the browser console I just get:

Uncaught ReferenceError: global is not defined

We released 1.3-modules-beta.2 today, with the following changes:

To try the new release, run:

meteor update --release 1.3-modules-beta.2
meteor update                              # to update the react and jsx packages
1 Like

Just to clarify, after upgrading I should remove meteorhacks:npm, re-add npm-container and install everything via npm install?

1 Like

Good question. I too would like to know the answer on this.

@csiszi No, in fact, you should just entirely remove meteorhacks:npm, then, at the root of your app, run

npm install whatever-package-you-want

and finally in your app code

import something from 'whatever-package-you-want'

There’s no need for meteorhacks:npm anymore (and you can delete npm-container).

5 Likes

@timfletcher ^ That comment for you too. :]

Awesome, thanks!

I currently use a package.json with some devDependencies (for some linting tools) and I noted in the current 1.2 docs that:

For compatibility with node.js tools used alongside Meteor, any directory named node_modules is not loaded anywhere. node.js packages installed into node_modules directories will not be available to your Meteor code.

So this will be different in 1.3. If I move all my meteorhacks:npm packages into package.json and run an npm install then Meteor will now be reading everything in node_modules. I guess that as my current modules are devDependencies that this actually is okay.

1 Like

@timfletcher That statement is essentially still valid with a new exception: files from node_modules won’t be loaded automatically, just as before, unless you explicitly load them with an import or require statement somewhere in your code. If you never import anything from node_modules, then those files will never load. However, if you have files outside of node_modules that you aren’t importing anywhere, then those files will be loaded automatically by Meteor unless they are inside any folder named imports.

I’m using various packages that are wrapping npm modules [1]
I’m seetnig errors like:

Uncaught ReferenceError: module is not defined
app.js:36 Uncaught TypeError: Cannot read property ‘Handsontable’ of undefined

here:

module.exports = exportModule(                                                                                     

this looks like node code for the original package to me.

I understand meteor now has a new way of requiring npm packages, but if the original npm package itself can’t find module… how do we work around that?

1 https://github.com/awsp/handsontable-meteor

OK so 1.3 seems to break wrapper packages, so I’m trying to debug how to use the new native meteor npm import features.

for others checking this thread, its important to do this:

mkdir node_modules

then

npm install whatever-package-you-want

and here are the docs:

so in my case I have added an npm package, but I am getting an error on trying to import it.

import Handsontable from 'handsontable';

Cannot find module ‘handsontable’

maybe that package itself is a bit funky as there was some discussion about npm support.

My question is - how do I figure out how to fix the import?

either the module identified by the main field of the package.json file, or index.js

The original module’s package.json has no main field and there is no index.js

So possibly that breaks meteor’s import feature?