Meteor 1.3 *early beta* now available

announce
101

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

102

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

2 Likes
104

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
105

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
106

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

1 Like
107

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

108

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

@timfletcher ^ That comment for you too. :]

110

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
111

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

112

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

113

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?

114

@dcsan I might have had a similar issue: https://github.com/meteor/meteor/issues/5866

But yeah, if the package doesn’t have an index.js and no main entry, then you might need to import the main file (or multiple files) manually.

import something from 'handsontable/path/to/something'
115

It doesn’t seem meteor.com is working with 1.3-beta and NPM packages?

Example Here.

116

@benjamn How do we use NPM with Meteor packages? Do we just npm install whatever we need, then meteor publish will bundle the stuff in node_modules?

2 Likes
118

Are there any 1.3 boilerplates like the kickstarts for webpack?

2 Likes
119

+1.

I’m trying to work out whether I can npm install browserify or do I still have to use cosmos:browserify. Github issues https://github.com/meteor/meteor/issues/5795 and https://github.com/meteor/meteor/issues/5825 do not present any obvious answers.

EDIT: Actually, I just got it working without having to touch browserify at all… Not sure if I’m doing it right but that was the last step in my port to 1.3! Loving the speedy build although my app is still pretty small.

I wouldn’t call my project a boilerplate or even a clean project (after the multiple refactors in the last month) but at least it’s finally running on 1.3 with a bit of react/redux sprinkled on and I can move on to actually adding content! YAYAYA!!

If you have the redux chrome extension, you can see Tracker updating the store with meteor subscription data (on game creation) as it comes back to minimongo . This way, I keep all client state in the store, propagate any updates to components via props thus keeping them pure and easy to unit test.

120

We’re hopefully going to launch something like this with the Meteor Guide alongside 1.3.

121

I’d like to reiterate a question that was asked earlier - how will this work with importing the same NPM package in multiple Meteor packages? Will the dependency tree be managed to ensure only one copy of each library is included?

122

@clayne Great question, and thanks for reiterating it. My current plan (slightly different from what’s implemented in the latest beta release) is that the top-level node_modules/ directory in an app will provide importable packages not only for application code but also for Meteor packages. In other words, the app gets to decide which version of an npm package will be used throughout the app and its packages. Packages can still use Npm.depends to install their own local dependencies, but they can also import or require npm dependencies that they did not explicitly install, with the expectation that the application will provide those dependencies.

So, to answer your question: no, the dependency tree will not be managed by Meteor, and there will be no special enforcement of single installation, but it should be straightforward for the app to provide a single version of a common dependency.