Meteor: Meteor 1.3 *early beta* (ES2015 modules, better file load order control, and more)

[avital]

We're starting the process towards Meteor 1.3, with module support, better NPM integration, better file load order configuration, and more.

Meteor 1.3 gives apps full ES6 (ES2015) modules support and better NPM support. Apps and packages can now load NPM modules that are installed via npm install on client and on server. Amongst other benefits, modules let you control file load order in much more precise way than naming your files in special ways.

To get feedback early, we decided to go ahead and release a beta release that doesn't yet have all of the features ready, but does have almost complete support for modules.

Try the release by running meteor update --release 1.3-modules-beta.8 in your app directory.

@benjamn wrote a great document explaining how to use modules in Meteor.

Please start trying this release out! You can start experimenting with switching your apps or packages to use the new module features. Let us know what works well or doesn't.

Take a look at the list of changes in Meteor 1.3, and the remaining tasks.

[guilhermedecampo]

Thanks for that! Looking forward to test modules! :+1:

[fakenickels]

Great work! Really excited about it, really cool that we can start getting rid of creating wrapper packages for npm stuff. :+1:

[vjau]

This seems to work great, thank you mdg.

[nicolasparada]

Nice.

[GeoffreyBooth]

Before you release the new module system, please make it compatible with CoffeeScript. In CoffeeScript, import and export are reserved words, so to write code that uses them requires using backticks, which looks really awkward. Ember.js apps built with Ember CLI have this same issue; such code looks like this:

`import Ember from 'ember'`

DummyController = Ember.Controller.extend()

`export default DummyController`

A simple solution is to follow the example of the ember-cli-coffee6 package, that does some simple string parsing to fix Coffee-style import/export statements before the regular Coffee compiler evaluates them.

[ciwolsey]

@avital Is import/export supposed to work from jsx? I've added the react meteor package but when using import/export from within jsx I get an error about usage of a reserved keyword.

[ccorcos]

@benjamn How do you feel about relative vs absolute file imports? It frustrates me when I have to write something like import Something from '../../lib/some/thing'. If I move the lib/some/thing file, then its going to be a huge pain in the ass chasing down all the relative paths to it and fixing them. And if I move the current file, the link breaks as well. In my webpack configuration, I resolve the root path to the root of my project so I never have .. in my imports. If I move a file, I can findAllAndReplace that absolute path with the new path trivially.

I saw your really nice presentation on ES6 modules and I'm curious what you think about this. Will this be supported in Meteor? How would this sort of thing work when publishing packages?

[benjamn]

@ccorcos there's been some debate about whether we should support module identifiers starting with a /, and your comment makes a strong case for "yes." The good news is that support for absolute paths is already implemented, so the debate is actually about whether it should be disabled, or remain enabled.

Now for the caveats…

In Node, an absolute module identifier corresponds to an absolute path from the root of the file system. Because we definitely don't want to include path prefixes like /Users/ben/dev/... in the client-side JS bundle, absolute module identifiers clearly need to work a bit differently from Node.

Instead, absolute module identifiers refer to the root of the virtual directory structure installed by meteorInstall. So, in your example, you could do

import Something from '/app/lib/some/thing';

if you wanted to avoid ../ paths. Though this behavior is admittedly not obvious, it's probably something we could commit to and document.

The situation with packages is similar, but somewhat more complicated-looking, because Meteor packages get installed with meteorInstall the same way npm packages are installed:

import PackageThing from '/node_modules/some-meteor-package/some/thing';

On the other hand, because of this structure, you probably never need to use an absolute module identifier to refer to a package, because you can just treat it as a top-level npm package:

import PackageThing from 'some-meteor-package/some/thing';

In other words, the ../../relative/path/problem is mostly something for apps to worry about, and /app/some/thing should help you avoid ../ paths.

[ccorcos]

@benjamn thanks for the explanation. Feeding off your presentation, I'm curious about this from a more generic sense -- how can this be compatible within Meteor and the rest of the NPM / Javascript community.

For example, within my webpack config, I simply tell it where it resolve absolute paths from:

      resolve: {
        root: [
          path.resolve(__dirname),
        ],
        modulesDirectories: [
          'node_modules'
        ]
      }

Then I don't even have to use the leading slash (which is ambiguous with the root of the filesystem as discussed):

import Something from 'app/lib/some/thing';

And by specifying the modulesDirectories, I can get away with this as well:

import PackageThing from 'some-meteor-package/some/thing';

The big caveat left in both the Meteor and the large Javascript community is that if I produce a package that uses these absolute paths (relative to the package's root), and then I start using it within another project, the packaging system needs to know what the package absolute paths are relative to the package root and not the project root. I believe this is still not a solved problem within the Webpack community.

@benjamn I'd also like to hear your thoughts about webpack's approach to bundling static assets (CSS, SCSS, Images, Fonts, SVGs, etc) within Javascript.

[raix]

:+1:

[TankOs]

Won't this feature also make it possible (or make it easier) to introduce bundlers, like Webpack? I'm especially concerned about build times, which would greatly benefit from tools like Webpack.

[trusktr]

@GeoffreyBooth Why are import and export reserved word in coffeescript? Is this a relic of times before ES2015 module syntax became a thing? Anyway, you can continue to use coffeescript, just add the coffeescript package. This works because compilers (provided by packages like coffeescript, ecmascript, less, etc) all do their transpilation work first, and then the new modules package handles the module aspects of the resulting _JavaScript_ files at the end. And since coffeescript is an official package, it will have support for compiling to CommonJS format no doubt. If the import/export syntax isn't in that package yet, then just use the CommonJS syntax (something like ember = require 'ember').

[trusktr]

@benjamn

import Something from '/app/lib/some/thing';

if you wanted to avoid ../ paths. Though this behavior is admittedly not obvious, it's probably something we could commit to and document.

The situation with packages is similar, but somewhat more complicated-looking, because Meteor packages get installed with meteorInstall the same way npm packages are installed:

import PackageThing from '/node_modules/some-meteor-package/some/thing';

On the other hand, because of this structure, you probably never need to use an absolute module identifier to refer to a package, because you can just treat it as a top-level npm package:

import PackageThing from 'some-meteor-package/some/thing';

I don't think this is a the best way to go, for some reasons:

1. Meteor package names can now collide with NPM package names. Perhaps require
   a colon in the name in order to differentiate, and meteor packages would always
   be prefixed with meteor: in this case.

js import PackageThing from 'some:package/some/thing' // or import PackageThing from 'meteor:package/some/thing'

This isn't part of NPM's spec, but it seems something like this is needed in
order to have zero chance of collision.

1. The meaning of an absolute path is not clear. A better bet would be for /
   to mean the app root in app code, and the package root in package code. Instead
   of writing

js import Something from '/app/lib/some/thing'

we can write

js import Something from '/lib/some/thing'

which is more intuitive (people won't go off wondering what else is in the
root if it isn't the app itself).

Additionally, some things that might help:

1. Treat the app as a package. We would be able to do

js import Something from 'app/lib/some/thing'

without the leading slash.

1. Allow a user configuration somewhere (perhaps modules.json) that lets us
   map names to paths (including paths that start with module names). For example

js { 'someLib': '/lib/some/thing', 'otherLib': 'npm-package/some/thing', 'anotherLib': 'meteor:package/some/thing' }

Now we can do

js import Something from 'someLib' import otherThing from 'otherLib' import anotherThing from 'anotherLib'

which would be useful for things we import repeatedly (and is simliar to what
@ccorcos describes Webpack having, and what Browserify, JSPM, and etc have).

[trusktr]

@ccorcos Also brought up a good point about the absolute paths and the meaning of it changing when using libraries in different environments. I think that the use of absolute paths should generally be discouraged in Meteor's case.

I'd also like to hear your thoughts about webpack's approach to bundling static assets (CSS, SCSS, Images, Fonts, SVGs, etc) within Javascript.

This is what packages the provide compilers will continue to be used for. For example, the coffeescript package will continue to compile coffeescript to javascript before Meteor 1.3's modules package does it's thing. So, these packages in the Meteor community (like coffeescript) are essentially equivalent to what loaders are in Webpack.

@TankOs

Won't this feature also make it possible (or make it easier) to introduce bundlers, like Webpack?

Nope, not at all. We can do that already, right now, without Meteor 1.3 (for example, my rocket:module package uses Webpack to let you write ES2015 modules). Webpack compiles code into a a compiled form that you run in the browser, which is what Meteor 1.3 is now doing too. You would either use Webpack (directly, or with packages like rocket:module), or use Meteor 1.3's modules package, but not both because both are tackling the same problem.

[TankOs]

@trusktr I see, interesting. I'll have a look at your implementation for getting some ideas. Thanks! :)

[ccorcos]

@trusktr

Treat the app as a package. We would be able to do import Something from 'app/lib/some/thing' without the leading slash.

I like this approach. You'd effectively need to symlink your project into node_modules, but then you can reference files with absolute paths just like any other package! Using a symlink is sort of a hack, but work would solve all of these absolute path issues at once :+1:

So, these packages in the Meteor community (like coffeescript) are essentially equivalent to what loaders are in Webpack.

I guess your right, actually. But then we have a similar problem as before where we have to create all these package shims. Theres a huge selection of webpack-loaders that are really nice to use:

1. Suppose you share a bunch of code between 5 different applications. Each component can require('components/styles/this_component.css') in JS for the CSS related to that component. Thus, your components are more modular.
2. The react-svg-loader is pretty cool and lets you inline SVG into a react component so you can style it with CSS.
3. The file-loader, url-loader, image-loader let you minify images, inline small fonts and images, and revision larger images, replacing with a url instead of inline.
4. There are all kinds of advanced techniques for gaining web performance like showing a small blurred inline photo while the larger one is loaded asynchronously. And the people building the tools for this are building them on top of webpack.

[trusktr]

You'd effectively need to symlink your project into node_modules

You wouldn't have to, the modules package would handle that behind the scenes.

I agree, there's tons we can do with Webpack that we won't immediately be able to do with Meteor 1.3. One thing (as you allude to) is that Webpack laoders don't just transform code, they also specify how to write import/require statements. So, even if Meteor 1.3 has compiler packages, there would still need to be an something additional implemented to let Meteor 1.3's modules package know how to handle certain imports (SVG files for example).

[trusktr]

Still, the name app conflicts with the app package on NPM, but it doesn't look like anyone is using that and it hasn't been updated for 4 years. Maybe meteor:app could represent the app, so

import Something from 'meteor:app/lib/some/thing'

?

[ccorcos]

What if it were just the name of your package?

[trusktr]

Then that's what it would be! ;]

[GeoffreyBooth]

@trusktr, import and export are reserved words in CoffeeScript because they were reserved words in ES5, per this thread where I and others have pleaded with CoffeeScript’s maintainers to add idiomatic support for ES2015 modules. Unfortunately it doesn’t appear that the other CoffeeScript maintainers have any interest in addressing this issue right now.

I’m glad that ES2015 is here and catches up to CoffeeScript with regards to the features that tempted many developers to CoffeeScript years ago. Many of those developers have switched back to ES2015, and more power to them; I’ve been using CoffeeScript for years primarily for the easier-to-read syntax, for the breath of fresh whitespace I get from fewer braces and parentheses and semicolons, and I don’t intend to stop coding in CoffeeScript just because JavaScript no longer sucks so much.

So please give us CoffeeScript diehards a way to use ES2015 modules in Meteor. Backticking ES2015 code in JavaScript is a pretty shitty solution, ugly and prone to error because you’re asking people to mix ES2015 and CoffeeScript in the same file. I think ember-cli-coffees6’s approach, letting me write import and export as idiomatic CoffeeScript that it fixes before the CoffeeScript compiler sees it, is probably the easiest “good” solution that you can do without hacking the CoffeeScript compiler. Better still would be if I could just use CommonJS require statements and module.exports like Node or Browserify, and Meteor pulls the packages together the same as if I had used import; at least the CommonJS approach would mean that only one transpiler is required (coffeescript) and not three (the Meteor version of ember-cli-coffees6, then coffeescript, then ecmascript). But I can see that supporting both CommonJS syntax and ES2015 syntax might be too much of a burden, so if that’s the case please implement something like ember-cli-coffees6.

Or if anyone knows @jashkenas or @michaelficarra or @satyr or @lydell or @alubbe or any of the other CoffeeScript maintainers, please convince them to stop ignoring this issue.

[lydell]

Just to clear some confusion regarding CoffeeScript:

• That import and export are reserved words in CoffeeScript is not relevant here (except that CoffeeScript could add support for them in a backwards-compatible way, which is good). CoffeeScript's parser simply does not support the export and import syntax, and the compiler is not able to emit such code (yet?).
• All of the pinged people in the above comment, such as me, might not necessarily:
  
  
  
  • consider themselves maintainers (but rather, for example, people who have managed to get several PRs merged)
  
  
  • share the disinterest in adding export and import syntax to CoffeeScript
  
  
• Basically, jaskenas is the one who decides what gets into the/his language.

(Also, I don't see how using backticks is _prone to error_ (but I agree that it is ugly):

`import {a} from 'a'`

b = ->
  a()

`export b`

The code in backticks are just "static declarations".)

Unsubscribing.

[alubbe]

Personally, I believe CoffeeScript should be a whitespace-based improvement of JavaScript, which should now include the finished ES6 syntax incl. import/export. That's why I built and lobbied for generator support - but as @lydell mentions, it's up to @jashkenas

If you really want to see it in CoffeeScript, I'd suggest to build it yourself and open a PR.

[prodogs]

Anyone else having trouble with 3rd party libraries. created a shell (Meteor create) runs fine then added a compatibility directory and inserted go-debug.js and it hangs building

[ccorcos]

What are the entry point on the client and the server?

[prodogs]

Didn't define them simply created new project and dropped go into compatability directory

[JeremyBYU]

Got this error recently. I emptied my meteor/local directory except the database and then reran meteor. Havent figured out how to fix it yet.

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/natty/.meteor/packages/meteor-tool/.1.1.11-modules.0.1mkz1hj++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
    at Array.forEach (native)
    at ImportScanner.getOutputFiles (/tools/isobuild/import-scanner.js:66:22)
    at Object.fullLink (/tools/isobuild/linker.js:969:8)
    at /tools/isobuild/compiler-plugin.js:686:28
    at /tools/utils/buildmessage.js:359:18
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at PackageSourceBatch._linkJS (/tools/isobuild/compiler-plugin.js:685:18)
    at PackageSourceBatch.getResources (/tools/isobuild/compiler-plugin.js:586:48)
    at /tools/isobuild/bundler.js:753:37
    at Array.forEach (native)
    at ClientTarget._emitResources (/tools/isobuild/bundler.js:736:19)
    at /tools/isobuild/bundler.js:515:12
    at /tools/utils/buildmessage.js:359:18
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at ClientTarget.make (/tools/isobuild/bundler.js:506:18)
    at /tools/isobuild/bundler.js:2199:14
    at /tools/isobuild/bundler.js:2288:20
    at Array.forEach (native)
    at Function._.each._.forEach (/Users/natty/.meteor/packages/meteor-tool/.1.1.11-modules.0.1mkz1hj++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at /tools/isobuild/bundler.js:2287:7
    at /tools/utils/buildmessage.js:271:13
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:264:29
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:262:18
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:253:23
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.capture (/tools/utils/buildmessage.js:252:19)
    at Object.exports.bundle (/tools/isobuild/bundler.js:2180:31)
    at /tools/runners/run-app.js:585:36
    at time (/tools/tool-env/profile.js:238:28)
    at Function.run (/tools/tool-env/profile.js:391:12)
    at bundleApp (/tools/runners/run-app.js:575:34)
    at [object Object]._.extend._runOnce (/tools/runners/run-app.js:628:35)
    at [object Object]._.extend._fiber (/tools/runners/run-app.js:880:28)
    at /tools/runners/run-app.js:402:12

Was wondering if something changed with the beta release that broke it. Or was it just me?

[ccorcos]

Didn't define them simply created new project and dropped go into compatability directory

Hmm. So the entry point is effectively deduced?

@JeremyBYU I also get an error just doing import React from 'react'

[JeremyBYU]

Okay I think I narrowed it down to an issue with the package.json I use to install my node modules. I think this is the offending text:

  "dependencies": {
    "formsy-react": "git+http://github.com/christianalfoni/formsy-react#4931256"
  },

It seems if I specify a git url and commit and not a version number that the 1.3 module system goes haywire. Should be simple to check. Create a new project, add a package.json with a dependency to a git commit, npm install, then run meteor. You should get a similar error. Be sure that the the meteor/local folder is empty before running meteor, if its not, you probably wont get the updated package.

[benjamn]

@JeremyBYU that's a bug that will be fixed in the next beta release

@avital can we do that today?

[prodogs]

awesome - will check again when available to see if things have changed.

i am assuming that with 1.3 you don't have to set an explicit entry point other than defining routes.

[JeremyBYU]

Oh awesome! Thanks you guys.

[ccorcos]

Ok. Maybe I'm entirely missing something, but I can't get this to work. Here's a simple application that just imports React on the client:

meteor create chatroom
cd chatroom
meteor update --release 1.3-modules-beta.0
rm chatroom*
mkdir client
cd client/
touch main.js
echo "import React from 'react'" >> main.js
cd ..
npm init
npm install --save react
meteor

And I run into this error:

Uncaught ReferenceError: process is not defined

Are there any example apps I can take a look at?

[JeremyBYU]

Hey @ccorcos ,
Heres a small sample app that I made LINK. Check out the readme. It should answer your question about react.

Thanks

[avital]

@ciwolsey Filed at https://github.com/meteor/meteor/issues/5827. We haven't yet updated the jsx package. It might just get unified with the ecmascript package.

[ccorcos]

@avital it seems alike a meteor.config.js file might be in order -- then we could set the specific babel plugins we want -- stage 2, jsx, etc.

[mitar]

+1 for support with CoffeeScript.

[avital]

Regarding CoffeeScript, is the request simply "let us use import/export with using backticks (`)?"

[benjamn]

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:

• Fixed typo where self was undefined, reported by @lampe and @jiku: #5812, #5799, fb73d9e3704556018310b7c873b4e7a95fac807c
• Made import and export work in .jsx files, though you'll want to use ecmascript instead of jsx now: #5827, 86b743f96346b66a7b79586823bbb92eeed8a83d
• The jquery package once again defines $ and jQuery globally, since some legacy code depends on that behavior: #5819, f241cbe44fb604396d39ef7839c940e727412569
• Fixed a bug that prevented loading directories as modules: fb73d9e3704556018310b7c873b4e7a95fac807c
• Now possible to import or require files with a .json file extension: #5810, 32fcced142eb6c03746333a29bc1bfb85040584e
• process.env.NODE_ENV is now defined as either "development" or "production", which makes some NPM packages (e.g. react) happier: dbebcd2d904c725b2634b6c26c5c1f29a79ecb25

[laurentpayot]

With this new beta (1.3-modules-beta.1) I get:

=> Errors prevented startup:                  

   While determining active plugins:
   error: conflict: two packages included in the app (jsx and ecmascript) are both trying to handle *.jsx

jsx package is automatically added when removed, and removing ecmascript leads to build errors as expected...

[mitar]

Regarding CoffeeScript, is the request simply "let us use import/export with using backticks (`)?"

I think what I would like to see is a non-backticks solution. But that is probably out of scope for Meteor to patch.

[vjau]

Same problem as @laurentpayot. But the jsx package isn't even the package list, i don't know where it comes from.

[vjau]

I guess the problem is that the react package implies jsx.

[bySabi]

cc @avital @benjamn @stubailo
1.3 beta related problems goes here or we must create a separate issue like we did on: https://github.com/meteor/meteor/issues/5831, https://github.com/meteor/meteor/issues/5832, https://github.com/meteor/meteor/issues/5824, https://github.com/meteor/meteor/issues/5819 ?

[vjau]

When doing import * as React from "react" (in login.jsx on line 1) i get following error from the browser console :

Uncaught TypeError: babelHelpers.interopRequireWildcard is not a function
meteorInstall.app.client.imports.components.blaze.login.jsx @ login.jsx:1
fileEvaluate @ install.js:183
require @ install.js:75
(anonymous function) @ app.js?hash=64c87f0e53426ff260637397dfc3bbb3dcd4e519:20410
(anonymous function) @ app.js?hash=64c87f0e53426ff260637397dfc3bbb3dcd4e519:20415

[JeremyBYU]

I seem to still be having issues that I referenced above with this new Beta.

Okay I think I narrowed it down to an issue with the package.json I use to install my node modules. I think this is the offending text:

"dependencies": {
"formsy-react": "git+http://github.com/christianalfoni/formsy-react#4931256"
},
It seems if I specify a git url and commit and not a version number that the 1.3 module system goes haywire.

There are no errors during the build this time, however I am unable to reference formsy-react. I have tried every combination I can think of (require, import, relative reference, etc.). If I change the dependency to a version number then everything works great again. Same steps to replicate as stated above.

EDIT: This might just be an issue with formsy-react at the specified commit. I tried this with moment and didnt have an issue. I'll keep investigating.

[laurentpayot]

Created #5849 for "error: conflict: two packages included in the app (jsx and ecmascript) are both trying to handle *.jsx"

[jiku]

@benjamn 1.3b1 solved it but uncovered some new issues. See comment on #5799.

[dcsan]

does this include fast rebuilds as per

[email protected]

i looked at the changelog but its not obvious...

[benjamn]

If you've been having problems with the jsx and ecmascript packages conflicting, please update to the latest version: [email protected]_1. In this version, the jsx package is implemented entirely by the ecmascript package, so there is no conflict.

[vonwao]

I get an error in browser when I try to upgrade my project to Meteor 1.3

I can track this down to this Reaktor package I'm using (reaktor allows you to define routes for flow router in JSX syntax), so maybe I could try to pull this out, maybe recent changes in Meteor cause Reaktor to break down.

However, per the suggestion above of @benjamn, I also don't know how to upgrade to react 0.14. My versions file shows I'm using 0.1.13, and I have no idea what's the way to upgrade react.

client.browserify.js:866 Uncaught TypeError: Cannot read property 'replace' of undefined replacePath @ client.browserify.js:866pathToRegexp @ client.browserify.js:901Route @ client.browserify.js:542page @ client.browserify.js:187(anonymous function) @ router.js:530_.each._.forEach @ underscore.js:105Router._updateCallbacks @ router.js:529Router.route @ router.js:129Route_componentWillMount @ kadira_reaktor.js:73ReactCompositeComponentMixin.mountComponent @ react.browserify.js:6804

[laurentpayot]

@benjamn when removing react and then adding [email protected]_1 I get:

$ meteor add [email protected]_1
 => Errors while adding packages:             

While selecting package versions:
error: Conflict: Constraint [email protected] is not satisfied by ecmascript 0.2.1-modules.1.
Constraints on package "ecmascript":
* ecmascript@=0.2.1-modules.1 <- top level
* [email protected] <- random 1.0.6-modules.1 <- autoupdate 1.2.5-modules.1 <- hot-code-push 1.0.1-modules.1 <- meteor-base 1.0.1
* [email protected] <- random 1.0.6-modules.1 <- caching-compiler 1.0.1-modules.1 <- coffeescript 1.0.12-modules.1
* [email protected] <- random 1.0.6-modules.1 <- mongo 1.1.4-modules.1
* [email protected] <- ddp-server 1.2.3-modules.1 <- ddp 1.2.2 <- allow-deny 1.0.1-modules.1 <- mongo 1.1.4-modules.1
* [email protected] <- ddp-server 1.2.3-modules.1 <- ddp 1.2.2 <- meteor-base 1.0.1
* [email protected] <- mongo 1.1.4-modules.1
* [email protected] <- allow-deny 1.0.1-modules.1 <- mongo 1.1.4-modules.1
* [email protected] <- http 1.1.2-modules.1 <- autoupdate 1.2.5-modules.1 <- hot-code-push 1.0.1-modules.1 <- meteor-base 1.0.1
* [email protected] <- templating 1.1.6-modules.1 <- blaze-html-templates 1.0.1
* [email protected] <- caching-html-compiler 1.0.3-modules.1 <- templating 1.1.6-modules.1 <- blaze-html-templates 1.0.1
* [email protected] <- caching-compiler 1.0.1-modules.1 <- caching-html-compiler 1.0.3-modules.1 <- templating 1.1.6-modules.1 <- blaze-html-templates 1.0.1
* [email protected] <- caching-compiler 1.0.1-modules.1 <- coffeescript 1.0.12-modules.1
* [email protected] <- templating-tools 1.0.1-modules.1 <- caching-html-compiler 1.0.3-modules.1 <- templating 1.1.6-modules.1 <- blaze-html-templates 1.0.1
* [email protected] <- templating-tools 1.0.1-modules.1 <- templating 1.1.6-modules.1 <- blaze-html-templates 1.0.1
* [email protected] <- reactive-dict 1.1.4-modules.1 <- session 1.1.2-modules.1
* [email protected] <- coffeescript 1.0.12-modules.1
* [email protected] <- jsx 0.2.4 <- react 0.14.3_1

[BodhiHu]

really excited to see meteor evolving so fast :tada:

[benjamn]

@laurentpayot yes sorry you'll also want to do meteor update --release 1.3-modules-beta.2 (just released today)

[laurentpayot]

Thanks @benjamn, I could upgrade to [email protected]_1 after installing 1.3-modules-beta.2.
But now I get:

~/meteor/simple-todos-react$ meteor
[[[[[ ~/meteor/simple-todos-react ]]]]]       

=> Started proxy.                             
=> Started MongoDB.                           

TypeError: Arguments to path.join must be strings
  at path.js:360:15
  at Array.filter (native)
  at Object.exports.join (path.js:358:36)
  at Object.pathJoin (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/static-assets/server/mini-files.js:86:16)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/import-scanner.js:53:32
  at Array.forEach (native)
  at ImportScanner.addInputFiles (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/import-scanner.js:52:11)
  at Object.fullLink (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/linker.js:959:8)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/compiler-plugin.js:673:28
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:361:18
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:354:34
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:352:23
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at Object.enterJob (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:326:26)
  at PackageSourceBatch._linkJS (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/compiler-plugin.js:672:18)
  at PackageSourceBatch.getResources (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/compiler-plugin.js:579:48)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:772:35
  at Array.forEach (native)
  at ClientTarget._emitResources (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:758:19)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:531:13
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:361:18
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:354:34
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:352:23
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at Object.enterJob (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:326:26)
  at ClientTarget.make (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:522:18)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:2178:14
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:2265:20
  at Array.forEach (native)
  at Function._.each._.forEach (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:2264:7
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:273:13
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:266:29
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:264:18
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:255:23
  at [object Object]._.extend.withValue (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/fiber-helpers.js:94:14)
  at Object.capture (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/utils/buildmessage.js:254:19)
  at Object.exports.bundle (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/isobuild/bundler.js:2161:31)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/runners/run-app.js:594:36
  at time (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/tool-env/profile.js:238:28)
  at Function.run (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/tool-env/profile.js:385:12)
  at bundleApp (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/runners/run-app.js:584:34)
  at [object Object]._.extend._runOnce (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/runners/run-app.js:637:35)
  at [object Object]._.extend._fiber (/home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/runners/run-app.js:899:28)
  at /home/laurent/.meteor/packages/meteor-tool/.1.1.11-modules.3.fmznxy++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/tools/runners/run-app.js:412:12

PS: I'm on Ubuntu 15.10.

[avital]

@laurentpayot looks like that's reported at #5871

[laurentpayot]

Thanks @avital . Suscribed.

[proehlen]

@benjamn wrote a great document explaining how to use modules in Meteor.

I'm having trouble working out how to create common modules that are used in both client and server code. I can get it working by copying the same code to the imports directory under both client and server. If I only put the code in an imports directory directly in the project root, it works on the client but not on the server.

[fakenickels]

@avital can you update the sayings Try the release by running meteor update --release 1.3-modules-beta.0 to Try the release by running meteor update --release 1.3-modules-beta.2?
Just to keep the first description up-to-date.

[dandv]

@splendido will have a bunch of free time now :)

[avital]

@grsabreu done, thanks for noticing

[Hamatek]

How can I use something like materiliaze-css once I update to 1.3 ?

The meteor package materialize:materialize doesn't seem to work for me anymore and with npm --save install materialize-css ... I am not sure how to use use materliaze-css for all my html any help with what I might be missing ?

[dcsan]

@Hamatek
i have similar problems with another package, but hadn't tried material ui yet.

https://forums.meteor.com/t/meteor-1-3-early-beta-now-available/14723/126
but i don't think MDG can detail how to fix each package.

how are you using materiliaze-css ?
are you using izzilab:material-ui ?

what you could do is look into the code of the package itself and see what they are loading. sometimes a "wrapper package" is not as simple as just pointing to an npm repo eg:
https://github.com/mrphu3074/react-material-ui/blob/master/package.js

in my case i'm trying to turn this back into module syntax
https://github.com/awsp/handsontable-meteor/blob/master/package.js
the irony is that this should be how things work more easily in the normal non-meteor world! once we get over these humps hopefully it will make it much easier to use NPM packages, but rather than meteor packages we'll probably need some type of recipes or guides as to how to actually get modules to work in practice with meteor. seems a bit case by case.

[mbrookes]

You'll have to explicitly add the modules package to use them (new apps going forward will have that package automatically added.)

Is that correct? I understood that the ecmascript package loads the modules package, so any existing app created at 1.2 or above (or upgraded to 1.2 or above and with ecmascript added) will have modules by default.

[avital]

@mbrookes You're right. I updated the text.

[mjmasn]

Would appreciate some info on:

1. The status of coffeescript with 1.3 / modules. Even the hacky backtick workaround doesn't seem to work here.
2. The upgrade path from 1.2 with a package-based app - I don't want to be rewriting 30+ packages to use modules.
3. A specific issue with api.addAssets([...html files...], 'server') in a package where Meteor appears to be trying to compile the files to be sent to the browser and error-ing because there's no <head>, <body> or <template>. They are partials for rendering into emails with SSR, so either are a full <html> page or just unwrapped html with no <body> or <template>. Is there a way to specify that a .html file should be left alone?

Spent a couple of hours on this yesterday and it sure seems like an 'everything is a breaking change' kinda update so far. I appreciate this is an early beta so hopefully that will change but I'm just looking for some reassurance here!

[avital]

Hi @mjmasn,

1. I was under the impression that the backtick solution does work. If not, could you please file a ticket with a simple repro?
2. All old packages should continue working. If not, that's a bug (one of those bugs was just fixed and will be released soon in 1.3-modules-beta.3)
3. Could you please file that as a separate issue and we'll look into it?

Thanks! This definitely should not be a "break everything" upgrade!

[benjamn]

New release!

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

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

Major changes:

• Absolute identifiers for app modules no longer have the /app/ prefix,
  and absolute identifiers for Meteor packages now have the prefix
  /node_modules/meteor/ instead of just /node_modules/, meaning you
  should import {Blaze} from "meteor/blaze" instead of from "blaze".
• Package variables imported by application code are once again exposed
  globally, allowing them to be accessed from the browser console or from
  meteor shell. #5868
• Fixed global variable assignment analysis during linking. #5870 #5819
• Changes to files in node_modules will now trigger a restart of the
  development server, just like any other file changes. #5815
• The meteor package now exports a global variable (a la Node) that
  provides a reliable reference to the global object for all Meteor code.
• Packages in local node_modules directories now take precedence over
  Meteor packages of the same name. #5933

[aykutyaman]

This import was working with 1.3-modules-beta.2:
import { SimpleSchema } from 'aldeed:simple-schema';
But with 1.3-modules-beta.3 it gives:

could not resolve module "aldeed:simple-schema"

How to import atmosphere packages?

[oskarkook]

@aykutyaman

Absolute identifiers for app modules no longer have the /app/ prefix, and absolute identifiers for Meteor packages now have the prefix /node_modules/meteor/ instead of just /node_modules/, meaning you should import {Blaze} from "meteor/blaze" instead of from "blaze".

So this is how you import Meteor packages:

import { SimpleSchema } from 'meteor/aldeed:simple-schema';

[johanbrook]

@benjamn Great job! I just installed beta 3 in our app, and it seems it bundles nested .css files in packages into the main CSS bundle.

Example: we've got

packages/
  bootstrap/
    .. files
    docs/
      docs.css

That docs.css file (and other Bootstrap CSS files) is apparently used when building the app, _without_ me adding it explicitly in the package's package.js. Not sure if I'm doing anything wrong, or if this is reported already.

[benjamn]

@johanbrook what do you mean when you say the .css file is used? Like, what's the symptom? Does it show up in the output in some form? Or are there errors when the file gets processed as if it were plain .css, because it contains some special syntax that you handle with some other tool?

Background: package files are now processed with compiler plugins even if they are never actually used, so I'm wondering how far we need to go down the path of making that processing lazy/invisible, for both performance and correctness reasons.

[johanbrook]

@benjamn

what do you mean when you say the .css file is used? Like, what's the symptom?

Sorry: it's included as the src in a link element in the app HTML when built. It was definitely not intuitive to me, and is kind of a breaking change.

package files are now processed with compiler plugins even if they are never actually used

Oh, so package files are added to the build pipeline even if they're not explicitly added?

[Hamatek]

Awesome update @benjamn nice work!

@dcsan hey thanks for your feedback, with this new update I can just do something like import { materialize } from 'meteor/materialize:materialize'; and it's all good :)

[jwvdiermen]

I get the following error with 1.3-modules-beta.3 when a local package tries to import a npm module:

Error: Can't find npm module 'classnames'. Did you forget to call 'Npm.depends' in package.js within the 'modules' package?

I do use Npm.depends in the package.js and import using the syntax (the error is from that line):

import classNames from 'classnames';

Am I missing something? The package has a dependency on ecmascript. Npm modules from the application itself via npm install in the node_modules folder work fine.

[benjamn]

New release!

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

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

Bugs fixed:

• https://forums.meteor.com/t/problem-with-import-using-1-3-modules-beta-3/16130
• https://github.com/meteor/meteor/issues/5963

[benjamn]

A new way to report bugs with modules

Your feedback during this beta period has been absolutely fantastic, so, first of all, thanks a ton for hammering on the module system, asking questions, and reporting bugs.

To make it even easier to provide reproductions and accumulate regression tests, I've pushed :sparkles: an example app :tada: that combines a bunch of tests that I've been running as part of my own local development workflow.

Here's my request: if possible, when you find a bug, please submit a pull request against this example app that introduces a failing test case.

I know there are going to be bugs that aren't easy to demonstrate with an app like this, so of course you are welcome to keep reporting bugs however you like. Pull requests just make my job a little easier.

[vjau]

When i run the test with beta4, i get the following error :

W20160111-22:54:45.952(1)? (STDERR) TypeError: Object [object Object] has no method 'interopRequireWildcard'
W20160111-22:54:45.952(1)? (STDERR)     at meteorInstall.node_modules.meteor.modules-test-package.server.js (packages/modules-test-package/server.js:3:19)
W20160111-22:54:45.952(1)? (STDERR)     at fileEvaluate (packages/modules/.npm/package/node_modules/install/install.js:183:1)
W20160111-22:54:45.952(1)? (STDERR)     at require (packages/modules/.npm/package/node_modules/install/install.js:75:1)
W20160111-22:54:45.952(1)? (STDERR)     at packages/modules-test-package/common.js:1:44
W20160111-22:54:45.952(1)? (STDERR)     at packages/modules-test-package/common.js:1:44
W20160111-22:54:45.952(1)? (STDERR)     at /home/vincent/dev/meteor/tools/tests/apps/modules/.meteor/local/build/programs/server/boot.js:242:10
W20160111-22:54:45.952(1)? (STDERR)     at Array.forEach (native)
W20160111-22:54:45.953(1)? (STDERR)     at Function._.each._.forEach (/home/vincent/.meteor/packages/meteor-tool/.1.1.11-modules.5.1h187nw++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160111-22:54:45.953(1)? (STDERR)     at /home/vincent/dev/meteor/tools/tests/apps/modules/.meteor/local/build/programs/server/boot.js:137:5

[jiku]

Should work if you try with the checkout, i.e. ../../../../meteor run.

[benjamn]

@vjau that should be fixed in the next beta: https://github.com/meteor/meteor/commit/3a9907aa3acbee84aaa5759bfcb241bf1fe8b229

If it's blocking you right now, I can do another release today.

[vjau]

Thank you @benjamn, i can wait for the next beta.
@jiku thank you, this is a newbie mistake on my part, however when i run the correct meteor, it's constantly stuck at "upadating package catalog" (four tries).

[GeoffreyBooth]

I agree with @benjamn about bug reports. I would appreciate if these threads were kept as a discussion of the release, not a stream of free-form bug reports. I was having a discussion earlier up this thread about how to require modules when not using ES2015, but I feel like our conversation got drowned out by a flood of “my app breaks in this!” comments.

[jiku]

@vjau maybe meteor reset (clearing out .meteor/local) helps? Sometimes does here.

[timothyarmes]

@benjamn Could you please create a new repository for your test app? If you wish us to use that as a basis for bugs then ideally we shouldn't have to for the entire meteor project! :)

[dagatsoin]

Is there a trick to get the source map _Line Number_ in the terminal when a error is thrown at build phase ?

I am using some .jsx file and here is the terminal output

W20160115-21:25:30.707(1)? (STDERR) 
W20160115-21:25:30.707(1)? (STDERR) /Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20160115-21:25:30.707(1)? (STDERR)                         throw(ex);
W20160115-21:25:30.707(1)? (STDERR)                               ^
W20160115-21:25:30.714(1)? (STDERR) TypeError: Cannot read property 'displayName' of undefined
W20160115-21:25:30.714(1)? (STDERR)     at getDisplayName (/Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/app/app.js:20894:26)
W20160115-21:25:30.714(1)? (STDERR)     at wrapWithConnect (/Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/app/app.js:21100:40)
W20160115-21:25:30.714(1)? (STDERR)     at meteorInstall.containers.VisibleTodoList.jsx (/Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/app/app.js:262:95)
W20160115-21:25:30.715(1)? (STDERR)     at fileEvaluate (/Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/packages/modules.js:196:9)
W20160115-21:25:30.715(1)? (STDERR)     at require (/Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/packages/modules.js:88:20)
W20160115-21:25:30.715(1)? (STDERR)     at /Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/app/app.js:22033:1
W20160115-21:25:30.715(1)? (STDERR)     at /Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/boot.js:242:10
W20160115-21:25:30.715(1)? (STDERR)     at Array.forEach (native)
W20160115-21:25:30.715(1)? (STDERR)     at Function._.each._.forEach (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160115-21:25:30.715(1)? (STDERR)     at /Users/vikti/dev/wizar-guide/.meteor/local/build/programs/server/boot.js:137:5

[codeNgamer]

@benjamn since the repo for the example app isn't up, I just figured i'd post this here. My issue is, this code correctly pulls the noble package but throws a 'cannot find module ./build/Release/binding.node'
My suspicion is meteor doesn't pull some dependencies for this package. i also have:

import sphero from 'sphero';

which works just fine when i remove:

import noble from 'noble';

[timothyarmes]

Meteor 1.3 support for Npm packages looks great, however if I include an NPM package in my project, and a meteor package Npm.require's it too, then we have duplication. This also occurs if two packages include Npm.require the same NPM packages.

To make matters worse, there's no easy solution. I hadn't written a more detailed post with a proposition to solve the problem, but in the end I posted it as an issue (https://github.com/meteor/meteor/issues/6013) instead.

I've still love to have the opinions of others here though. Perhaps I'm missing something obvious?

[clayne11]

I mentioned this problem in the forum as well and started a post to discuss it but nobody has commented on it.

See here if you have some suggestions:
https://forums.meteor.com/t/meteor-1-3-npm-packages-in-atmosphere-packages/15942

[matb33]

I'm busy refactoring a large project from all-packages to module-based -- liking it very much so far. My biggest complaint with the beta so far is the lack of filename in the error reporting when there's a syntax error. In fact, the server just quits instead of trying to restart until the error is fixed, and the error message gives me only line:col. With thousands of files, this becomes an interesting guessing game :)

[dagatsoin]

@matb33 exactly the same issue. Something is going wrong with my ES6 script and all I got in the terminal is this:

MacBook-Pro-de-vikti:wizar-guide vikti$ meteor
[[[[[ ~/dev/wizar-guide ]]]]]                 

=> Started proxy.                             
=> Started MongoDB.                           

SyntaxError: Unexpected token (18:26)
    at Parser.pp.raise (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/location.js:24:13)
    at Parser.pp.unexpected (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/util.js:82:8)
    at Parser.pp.parseExportFrom (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/statement.js:737:12)
    at Parser.pp.parseExport (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/statement.js:678:10)
    at Parser.parseExport (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/plugins/flow.js:679:20)
    at Parser.pp.parseStatement (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/statement.js:115:90)
    at Parser.parseStatement (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/plugins/flow.js:621:22)
    at Parser.pp.parseTopLevel (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/statement.js:30:21)
    at Parser.parse (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/parser/index.js:70:17)
    at Object.parse (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babylon/lib/index.js:45:50)
    at Object.parse (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/node_modules/babel-core/lib/api/node.js:160:21)
    at Object.parse (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-babel/index.js:12:32)
    at tryToParse (/tools/isobuild/js-analyze.js:7:12)
    at Object.findImportedModuleIdentifiers (/tools/isobuild/js-analyze.js:52:15)
    at ImportScanner._scanDeps (/tools/isobuild/import-scanner.js:114:23)
    at /tools/isobuild/import-scanner.js:177:27
    at Array.forEach (native)
    at Function._.each._.forEach (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++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:116:5)
    at /tools/isobuild/import-scanner.js:82:26
    at Array.forEach (native)
    at ImportScanner.getOutputFiles (/tools/isobuild/import-scanner.js:79:22)
    at PackageSourceBatch._linkJS (/tools/isobuild/compiler-plugin.js:615:10)
    at PackageSourceBatch.getResources (/tools/isobuild/compiler-plugin.js:590:48)
    at /tools/isobuild/bundler.js:753:37
    at Array.forEach (native)
    at ClientTarget._emitResources (/tools/isobuild/bundler.js:736:19)
    at /tools/isobuild/bundler.js:515:12
    at /tools/utils/buildmessage.js:359:18
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at ClientTarget.make (/tools/isobuild/bundler.js:506:18)
    at /tools/isobuild/bundler.js:2199:14
    at /tools/isobuild/bundler.js:2288:20
    at Array.forEach (native)
    at Function._.each._.forEach (/Users/vikti/.meteor/packages/meteor-tool/.1.1.11-modules.5.6yllly++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at /tools/isobuild/bundler.js:2287:7
    at /tools/utils/buildmessage.js:271:13
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:264:29
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:262:18
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:253:23
    at [object Object]._.extend.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.capture (/tools/utils/buildmessage.js:252:19)
    at Object.exports.bundle (/tools/isobuild/bundler.js:2180:31)
    at /tools/runners/run-app.js:585:36
    at time (/tools/tool-env/profile.js:238:28)
    at Function.run (/tools/tool-env/profile.js:391:12)
    at bundleApp (/tools/runners/run-app.js:575:34)
    at [object Object]._.extend._runOnce (/tools/runners/run-app.js:628:35)
    at [object Object]._.extend._fiber (/tools/runners/run-app.js:880:28)
    at /tools/runners/run-app.js:402:12

Good luck with that ! :)

[ndarilek]

Is the client/compatibility directory no longer supported? I have a couple files that need to define globals, but I don't see them referenced in the HTML nor do I see their globals defined.

[dagatsoin]

Maybe worth to post it here. https://github.com/meteor/meteor/issues/6054

material-ui is not actually usable due to dual React version loading

Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's `render` method, or you have multiple copies of React loaded.

[markshust]

I have material-ui working fine with 1.3 (however, I'm sneaky and using the non-mentioned 1.3-modules-beta.5). Note that I installed react with npm in package.json (like it should be). I'm getting mat-ui elements to appear just fine :)

UPDATE: I put it up online if you want to check out the setup. It's very basic. https://github.com/markoshust/meteor-1.3-demo-material-ui

[benjamn]

New release!

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

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

New features:

• Packages in the top-level node_modules directory of an app can now be imported by Meteor packages: c631d3ac35f5ca418b93c454f521989855b8ec72
• Upgraded babel-compiler to Babel 6, with the following set of plugins: https://github.com/meteor/babel-preset-meteor/blob/master/index.js
• Lazy CSS modules may now be imported by JS: 12c946ee651a93725f243f790c7919de3d445a19
• Added support for wildcard import and export statements. #5872 #5897

The Babel upgrade was a pretty substantial change, so I anticipate there will be some minor transform-related bugs.

[ShimShamSam]

I was told async/await would be available in this release, yet I still get "unexpected token" errors when using the await keyword

[ndarilek]

Apologies for the noise, but has anyone had time to look at #6047, or is it a misunderstanding on my part? Seems like a pretty huge breaking change if the client/compatibility directory works differently in 1.3. It is only used on one project for me, but that particular library needs it and without a workaround this is a blocker for me.

Thanks.

[benjamn]

@ShimShamSam here's a test that seems to work for me: https://github.com/meteor/meteor/commit/2c1083feb3bdc10d74680866e95eac597ff742bc

Were you hoping that await could be used outside the body of an async function?

[timothyarmes]

Upgrading from beta 4 to beta 5 I can no longer 'compile' since there are now parsing issues that we didn't have before. Details submitted at #6073.

[ShimShamSam]

@benjamn Ah, yes. I'm dumb. Thanks

[djhi]

@benjamn awesome work ! This make it really easy to work with React & Redux. Thx :)

Lazy CSS modules may now be imported by JS

Is it supposed to work with scss/styl/etc. too ?

[cesar2535]

beta 5 has broken destructuring imports when the source was export an object with default.

// utils.js
export default {
  x: {
    log: function () {
      console.log('X')
    }
  }
  y: "Y"
}

// main.js
import { x, y } from "./utils.js"

x.log()
// TypeError: Cannot call method 'log' of undefined

[dferber90]

@cesar2535 I think that shouldn't have worked in the first place.
import { x, y } from "./utils.js" is for importing the named exports from utils.

See: http://stackoverflow.com/questions/33524696/es6-destructuring-and-module-imports

[cesar2535]

@dferber90 Got it. So, Is it a bug that worked at the 1.3-modules-beta.4?

[dferber90]

And probably the ones before that. I think it's due to the upgrade of babel-compiler to Babel 6.

[dagatsoin]

@markoshust thank you so much! I am stuck on this for a week because I have used Meteor react package !

[tngo10]

I have an all-package app in which a couple of packages depend on the npm react module. This seems to make multiple copies of react loaded and I got this error:

Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's render method, or you have multiple copies of React loaded.

How to resolve this?

[dagatsoin]

@tngo10 make sure you are not using meteor react package which comes when you do meteor install react.
Also, some people have trouble because NPM 2.x which install react multiple times. Switching on NPM 3.x could resolves this.

[dotansimha]

Is there any alternative for adding assets? like CSS and HTML files that packages need to declare that it uses, like support for import 'a.html' and Meteor will trough this file inside the HTML compiler.

[tngo10]

@dagatsoin thanks for answering. I'm pretty sure that I don't include meteor react package. Also, I'm using Node v5.3.0 and npm 3.3.12. Here's the sample code:

https://github.com/tngo10/meteor-and-react

[markshust]

Never mind -- all working ok (packages jail prob).

[markshust]

I'm encountering an infinite loop of sorts within the build process trying to perform an upgrade of 1.2 to 1.3.

A model of mine is not being found:

W20160127-18:29:16.114(-5)? (STDERR) ReferenceError: mymodel is not defined
W20160127-18:29:16.115(-5)? (STDERR)     at meteorInstall.mymodel.lib.collections.js (mymodel/lib/collections.js:1:1)
W20160127-18:29:16.115(-5)? (STDERR)     at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:183:1)
W20160127-18:29:16.115(-5)? (STDERR)     at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:75:1)
W20160127-18:29:16.115(-5)? (STDERR)     at /Users/markshust/Sites/myapp/frontend/.meteor/local/build/programs/server/app/app.js:10016:1
W20160127-18:29:16.115(-5)? (STDERR)     at /Users/markshust/Sites/myapp/frontend/.meteor/local/build/programs/server/boot.js:242:10
W20160127-18:29:16.115(-5)? (STDERR)     at Array.forEach (native)
W20160127-18:29:16.115(-5)? (STDERR)     at Function._.each._.forEach (/Users/markshust/.meteor/packages/meteor-tool/.1.1.12-modules.5.3i2h8a++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160127-18:29:16.115(-5)? (STDERR)     at /Users/markshust/Sites/myapp/frontend/.meteor/local/build/programs/server/boot.js:137:5
=> Exited with code: 8                        
W20160127-18:34:58.990(-5)? (STDERR)          
W20160127-18:34:58.992(-5)? (STDERR) /Users/markshust/.meteor/packages/meteor-tool/.1.1.12-modules.5.3i2h8a++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20160127-18:34:58.992(-5)? (STDERR)                            throw(ex);
W20160127-18:34:58.992(-5)? (STDERR)            

When I initially start the build, my app is around 400mb (du -sh within .meteor). However, on the above error, it never stops -- just keeps trying to build, even when it shows the above error. When I killed it after 30 mites of building, the .meteor directory was 2.2gb.

I'm not sure why this error is even occuring either, as this is the line that is bombing out:

mymodel = new Mongo.Collection('mymodel');

[fallenpeace]

@markoshust In beta 5, globals are having issues. Usage for mymodel should be global.mymodel (for now i hope)

[dagatsoin]

@markoshust same here and global. fixes the issue. But should not be more ES6 way to use export/import instead of global?

[markshust]

@fallenpeace @dagatsoin thank you, that resolved that issue. I actually don't completely mind this because it explicitly tells us what is global and what isn't. I do think for seamless upgrades though this should probably be resolved to save a lot of grunt work.

Is the react-meteor-data higher order component method already working with this package as noted here, or is this still being developed? https://github.com/meteor/react-packages/issues/169

Note to all that this isn't a seamless upgrade if you already have a project using Meteor's React. There are major changes in how data is pulled in and routing support for SSR is still under development. I'm upgrading and while it doesn't seem horrible yet, there is a lot of uncertainty right now in if this will all work :)

[markshust]

I managed to upgrade a (fairly) small app. I should rearchitect my container components so they work better with react-komposer (that did work but looked overly verbose, because I need to refactor). However, I came across this great plugin which seems to work great https://github.com/ultimatejs/tracker-react. It allows you to keep just about the same format as ReactMeteorData (just renamed getMeteorData() to data(), then call this.data() instead of this.data). It's a quick hack to make things very easy to migrate to 1.3 until more time can be spent refactoring for react-komposer. Thought some others may want to know about this.

That said, rebuilds are taking for-ev-er (one minute+ per new file save to reload). I'm not sure what is going on in the build process to cause this. I ported all dependencies for React out of Meteor and into npm, and that seems to be working great.

Cheers,
Mark

[marbemac]

@markoshust let me know if you find a way around the rebuild issue - we had to pause our 1.3 attempt because of rebuild times. More information here:

https://forums.meteor.com/t/help-us-test-build-times-in-meteor-1-3/15031/24

[ndarilek]

Is there a fix for the globals issue in the works anytime soon? I'm slowly refactoring my app to modules but have definitely hit this one.

[markshust]

@marbemac I replied back https://forums.meteor.com/t/help-us-test-build-times-in-meteor-1-3/15031/26?u=markoshust and followed up at https://github.com/meteor/meteor/issues/6058 -- definitely noticing something wonky going on.

@ndarilek prefix everything with global.. I don't see any downside in keeping these around forever, as it will help you identify what is global or not for refactoring purposes in the future.

[dgreensp]

I'm pretty sure globals breaking is an inadvertent result of the upgrade to Babel 6 (which outputs "use strict" where Babel 5, as we configured it, didn't), but @benjamn can confirm. It breaks the example apps, for example.

[ndarilek]

Sure I can prefix things with global, but then let's call this what it
is: Meteor 2.0.

I'm fine with that if MDG wants to take that route, but this is a
breaking change, and it definitely makes me less interested in dipping
my toe in the water with other apps (I.e. adding the modules package and
gradually transitioning over.) I'm likely to put off upgrading due to
this breaking change.

[mbrookes]

@dgreensp Babel 6 is, rightly or not, breaking lots of things because of this change: https://github.com/callemall/material-ui/issues/2802#issue-125081211

This is the Babel issue where it was discussed at length: https://phabricator.babeljs.io/T2212

[trusktr]

@cesar2535

Based on the actual es6 module spec, it should be:

// main.js
// import { x, y } from "./utils.js" // should not work.
import utils from "./utils.js" // get the default export

utils.x.log() // it works

where utils can be any name you want, f.e.

import blahblah from "./utils.js"
blahblah.x.log()

Other behavior may have been a "bug" in the Meteor implementation.

You can get an idea of the expected behavior from the Babel "repl".

[benjamn]

@dgreensp and @mbrookes are correct, and what we probably need to do is to strip the "use strict" from compiled files, if there is no way to prevent Babel from adding it.

[ndarilek]

So before Meteor 1.3, I had this ugly code in authentication.js:

passwordResetToken = null
emailVerifyToken = null
authDoneCallback = null

Then, because password reset/email verification is triggered off of the / route with no way to change that (that I know of), I had to put password reset/verification code in home.jsx that accesses and sets this global state. I'd have liked to contain that code in its own routes/components defined in authentication.jsx but didn't find a way to do that.

Now I'd like to modularize this, so I tried:

export let passwordResetToken = null
export let emailVerifyToken = null
export let authDoneCallback = null

then importing those variables into home.jsx. But when I try setting them, to clear the state so the reset logic doesn't trigger, I'm told they are read-only.

Is there a way to modularize this state and still have write access? Or, better yet, can I move this reset logic into separate routes so I don't have to roll this unrelated logic into my home template, and can instead handle it in /emailverify or /passwordreset routes?

Thanks.

[ndarilek]

Just to be clear, I ask this here and not in the forums because I think this is one area of Meteor's architecture where it seems to me you kind of _have_ to shove stuff into global state. I've been exporting models and React components and gradually making my app more modular, so I was surprised when I couldn't do that with these variables. Ideally I'd like to move the logic to its own self-contained components and routes, but if that isn't possible then I guess I'll need write access to these exported variables. Maybe there's another way I'm missing.

[reohjs]

@ndarilek That is expected behaviour since we are still transpiling to CommonJS. See: http://www.2ality.com/2015/07/es6-module-exports.html

Use an object instead:

export const resetState = { 
  passwordResetToken: null,
  emailVerifyToken: null,
  authDoneCallback: null
}

[ndarilek]

Thanks, that works.

[dagatsoin]

I am actually trying to use Modules CSS with React.

I am importing renamed .css files in .wss file (eg import style from style.wss). Renaming extension prevents Meteor to compiles and avoir global css variables.
Those files are compiled by webpack and then reinjected as a single app.css file in Meteor.

The problem is that Meteor compiles just css and js files and does not care about other extensions. So I have errors like Error: Cannot find module './map.xss'

So are there plans to support special files extensions or compile options?

[juliancwirko]

yeah, It would be great to have 'CSS Modules' in the core and also (or at least) possibility to import .styl or .less files from node_modules in main .styl or .less files in the app (and later .scss too - I hope so). I think this is quite important stuff when we want to use React and ES6 modules in Meteor instead of standard Meteor packages.

[benjamn]

New release!

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

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

Changes:

• Circular package.json resolution chains are no longer forbidden. #6114
• return statements are now allowed at the top level. #6144
• "use strict" is no longer injected at the top of every module file, which reenables "global" variable assignments. #6072 #6086
• Added the babel-runtime/helpers/slicedToArray helper, fixing #6076.
• Numerous profiling and performance improvements, thanks to @dgreensp. More to come!

[markshust]

@benjamn this is a great release. performance improved drastically over beta5.

[dotansimha]

@dagatsoin @juliancwirko you both right... you may look on this issue I created: https://github.com/meteor/meteor/issues/6098 , this is not just CSS files, it's all type of assets (fonts, templates, images, etc..)

[dagatsoin]

@dotansimha so React (https://github.com/nathantreid/meteor-css-modules/issues/1#issuecomment-180076417) + Angular 2 need this. Is there any plan for this?

[benjamn]

New release!

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

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

Changes:

• The meteor command-line tool (including the build system) is now implemented using Babel 6.
• async functions are now guaranteed to execute in a Fiber: 8497c0a5d2f6b2bafd8c0e468d7c2490aeb1cbbb
• Rebuilds now happen in-place, leading to better performance: fabb20d2cde1e85d71c6730fdede5a3bbfc1e2ac
• Parse errors during dependency scanning are now shorter and more useful: #6009
• We merged the devel branch into the release-1.3 branch: a05b81af8d419ab08e41c40291568a544240e324

[trusktr]

@benjamn Awesome! What's the benefit of using a Fiber for async functions (I'm curious to learn)? How does it compare to using a pure JavaScript shim (f.e. using Promises but not Fibers / not modifying or extending the JavaScript VM)?

[ndarilek]

Seeing this over and over on beta7:

E20160205-10:48:23.579(-6) (webapp_server.js:716) Error running template: Error: Meteor code must always run within a Fiber. Try wrapping callbacks that you pass to non-Meteor libraries with Meteor.bindEnvironment.

That is unfortunately it. No indication where the error is happening. Occurs every time I load a page and nothing renders. If I'm doing something incorrectly then I'll fix it, but I don't know what code I've written or what other package I'm using might be causing that.

Switching to beta.6 for the time being as that makes it go away.

[benjamn]

@ndarilek can you file a separate issue and provide a repro if possible?

[ndarilek]

Sure, I'll file a separate issue, but reproducing may be difficult since
a) I'm on a deadline b) the app is fairly large and c) the error doesn't
provide a stacktrace. If it did then it'd be easier to debug.

[dgreensp]

@ndarilek, webapp_server.js is rendering the page on the server, so I'd look in whatever server-side rendering hooks you have. I committed a change that should give you a stack trace in the next beta.

[jamiter]

The meteor command-line tool (including the build system) is now implemented using Babel 6.

Does this give any benefit to app developers? Or only for the people who develop the command line tool?

For instance: package.js couldn't be written in ES6 before, can we do that now?

[dagatsoin]

I dive in the doc of 1.2 for the build API and I begin to perceive the start of something I may barely called an understanding. Question, is there upgraded doc for 1.3?

[dgreensp]

No, I don't think that API has changed much or at all.

[dagatsoin]

But @benjamn seems to talk about compile plugin in meteor 1.3 https://forums.meteor.com/t/why-is-the-meteor-install-1-3-api-better-than-webpack-in-meteor/14480/46?u=vikti

But there are already available in 1.2.

[dgreensp]

Hi @dagatsoin, Ben didn't mean that compiler plugins are new, he meant that with modules being new in 1.3, your compiler plugin can do something Webpack-like and turn a .png into a module.

What was new in 1.2 was the ability to write compiler plugins that e.g. can work on multiple files at once that span packages (e.g. LESS with imports), do caching, and act like minifiers and linters: https://github.com/meteor/meteor/wiki/Build-Plugins-API

[benjamn]

New release!

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

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

Changes:

• No longer assuming strict mode when parsing ECMAScript files: ae90250f80bc705f46c81d8a97ce252a77b0145c
• meteor create --package new-package will now create a package that uses modules: ecf4fdb7b4660e51727dc9153a419f0c243eabb4
• Client modules imported by server modules will now be properly compiled: 35a02864aff85c829cb509f2bcbb8dfe67a64848
• Upgraded fibers package to 1.0.8: c23a001d98875eb152cee6b5830066011b7380ad
• Constraint solver now attempts to verify the previous solution first: d6e9921bbbf33943ce3c1f64ec4224d751eaf163
• Template errors now have better stack traces: bd213e143b4eda504f4eb04f459abf03666ddbc4
• Tool and server module sizes have been reduced by not generating line number comments: 05ac1c1df2e1a6d900e426f0cae906d06b59a49c
• Dependency scanning now caches fs.stat calls, and uses fs.statSync for better performance: 58534baa80eefd3f2b976e8261fa3020b9bac433, 2afe4f5767b6bf0d195d8bd0f0fe24de643d29b4
• Apps that crash within 8 seconds are limited to 3 restarts: e50b18277269589536b5ef4493da24a19d63a80b

[ffxsam]

Great work as usual! :tada:

[ffxsam]

Am I imagining things, or was it previously not possible to import objects from the server into the client? Now I'm able to.

[pward123]

Just tried out beta 8. Seems to work great for me so far. The only issue I ran into is the facts package throwing this error:

Exception in defer callback: TypeError: Object [object Object] has no method 'publish'
    at runWithEnvironment (packages/meteor/dynamics_nodejs.js:110:1)
    at packages/facts/facts.js:51:1

[GeoffreyBooth]

Hi @benjamn or @avital, what’s the recommended way to use CoffeeScript with modules in 1.3? Backticks? CommonJS syntax? Please include a note about this in the documentation.

P.S. CoffeeScript is getting with the program and will eventually support ES2015 modules, but it will likely take a while.

[marbemac]

Love these rapid fire releases, and involvement from MDG in these threads! It's like waking up to a present every morning, keep it up :).

Might I suggesting outputting some simple timing info? For example, with the client refresh, it would be handy to know how long that last refresh took - even as simple as a ms number next to the (8x) in the image below. Something we've done has increased rebuild times (not build times) dramatically, and we're trying to figure out what that is, so that we can give that information to @dgreensp. Simple timings would help our crude debugging efforts.

[markshust]

With 1.3beta6, I was able to build a Docker image from a meteor build from the node:0.10.41-slim image, resulting in a Docker image that was 269mb. Great. However, with 1.3beta8, the slim image no longer works, and I must use node:0.10.41, as it seems to need build-essential, python, and a few other deps installed. This is ok, however this same script now builds an image that is 733mb. Is there something that was introduced in beta 7 or 8 that is needing these req's installed, and/or is there any way to slim down this prod image (cleanup script?)?

[gadicc]

@marbemac, did you see the new tools/PERFORMANCE.md ? Some great hints on profiling.

[marbemac]

Nope. Holy crap yes. Thanks!

On Sunday, February 7, 2016, Gadi Cohen [email protected] wrote:

@marbemac https://github.com/marbemac, did you see the new
tools/PERFORMANCE.md
https://github.com/meteor/meteor/blob/release-1.3/tools/PERFORMANCE.md
? Some great hints on profiling.

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5788#issuecomment-180975274.

[dotansimha]

Having some weird issues with 1.3 + TypeScript compiler and mainModule: https://github.com/meteor/meteor/issues/6185

Any idea?

[newsiberian]

With beta-8 Chromium dev tools goes crazy! You just can't put breakpoint on the place in 8 times from 10.

[dotansimha]

@newsiberian same here with latest Chrome... something wrong with the source maps I think... put a breakpoint and it put it in the beginning of the file...

[dgreensp]

If that was me in 9696ee0, that should just be reverted since maybe I
didn't know what I was doing.

On Monday, February 8, 2016, Dotan Simha [email protected] wrote:

@newsiberian https://github.com/newsiberian same here with latest
Chrome... something wrong with the source maps I think... put a breakpoint
and it put it in the beginning of the file...

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5788#issuecomment-181387207.

[dagatsoin]

I can not compile for Cordova anymore. Maybe it is because the Cordova project is developed in parallel?

[avital]

@dagatsoin The new Cordova work is happening in parallel, but may ship as 1.3.1 not 1.3. So all existing Cordova features should work on the 1.3 branch. If they don't, please file a new GitHub issue with a repro.

[timothyarmes]

I just fell upon the following comment over here

As for meteor 1.3, in theory it should work if you just use the ReactLayout package without any hitch as the meteor React package now just loads up React from npm if you have it installed.

I've been trying to find some reference to this in the recent release notes, but I can't find anything. Can someone please confirm:

• Is this true that using the React package will use React from Npm if installed by the app?
• Is this specific the react package, or or is it general to any package that uses Npm.depends?
• If it's general, does that mean that using Npm.depends in a package will use the app's Npm version if it's installed?
• Where was this documented?

Thanks

[alphashuro]

@timothyarmes take a look at the release notes for beta.5

meteor update --release 1.3-modules-beta.5
New features:
Packages in the top-level node_modules directory of an app can now be imported by Meteor packages: c631d3a

I think this essentially means that if you use Npm.depends in any package then meteor will resolve the depended upon package using the top-level node_modules directory.

[timothyarmes]

Thanks @alphashuro, that's rather useful information :)

[avital]

@GeoffreyBooth backticks. Can you help by filing a pull request to fix the docs?

[GeoffreyBooth]

@avital Yes.

[clayne11]

@alphashuro I don't believe that's true. It simply means you can import packages in the top level node_modules directory into packages.

As far as I understand Npm.depends pulls the dependency directly into the package and that isn't going to change for this release. If you use Npm.depends and install the module at the top level you can end up with two copies of the same package in the final bundle.

[avital]

Npm.depends is now something that should realistically only be used for packages with binary dependencies. It's far easier to just npm install packages into your app or package. Nothing has changed with Npm.depends for this release.

[timothyarmes]

That's unfortunate. So then, can someone tell me if it is this true that using the React package specifically will use React from Npm if installed by the app?

The problem being, of course, that we wish to be able to continue using existing packages that depend on React whilst also being able to use the Npm version directly along with any other Npm packages that depend on it.

[avital]

@timothyarmes The new pattern for using react is to install react via npm install react in the top-level of your app, and only use the react-meteor-data package from Meteor

[ffxsam]

And use react-mounter to replace the Meteor kadira:react-layout package.

[mbrookes]

@ffxsam - why?

[ffxsam]

Because using kadira:react-layout will install the Meteor version of React, which will collide with the NPM version.

[mbrookes]

Oh. :-/ That's not so good then! Is that fixable, or do Meteor packages have to install all their dependencies, even when already installed via npm?

[ffxsam]

It depends on the package, really. Some Meteor packages that require React will still require the Meteor/Atmosphere version. I expect this to standardize more in the future, and I'm assuming people will eventually move over to using the React package in the NPM registry instead. Just be wary of adding React packages in Meteor, and when you see them install react, you'll probably have to go with another solution.

[avital]

Worth pointing out that a future version of the react Meteor package will no longer install React, rather tell users to run npm install react in their app.

[ffxsam]

Not to split hairs, but will it say npm install --save react? (just to be clear, for those who may be new to npm and don't realize that they need the --save option)

Actually, would it be better to recommend they do npm install --save react react-dom?

[avital]

@ffxsam Yeah

[GeoffreyBooth]

@avital, it appears that backticks for module import in CoffeeScript don’t work. I cloned the todos repo (at 1.3-modules-beta.8) and converted a few of its files to CoffeeScript. The JavaScript files that are generated from the CoffeeScript don’t get processed any further, and so the import statements get passed through all the way to the browser, which doesn’t like them:

Uncaught SyntaxError: Unexpected token import

_However,_ CommonJS syntax works great! For example, I can rewrite this:

import { FlowRouter } from 'meteor/kadira:flow-router';
import { BlazeLayout } from 'meteor/kadira:blaze-layout';
import { AccountsTemplates } from 'meteor/useraccounts:core';
import '../imports/startup/client/routes.js';

as this:

{ FlowRouter } = require 'meteor/kadira:flow-router'
{ BlazeLayout } = require 'meteor/kadira:blaze-layout'
{ AccountsTemplates } = require 'meteor/useraccounts:core'
require '../imports/startup/client/routes.coffee'

and it just works! Should we perhaps advise in the docs that CoffeeScript coders simply use CommonJS syntax? I feel like using CommonJS must be faster when it comes to build times, as the code would only need to be transpiled once instead of twice. Even if there’s some way to make backticks import/export work, is there any advantage to that over CommonJS?

I’m also happy to move this discussion to email or a dedicated issue or forum post if you’d like.

[avital]

@GeoffreyBooth Thanks for looking into this! Given that CoffeeScript will eventually support ES6 imports, let's just recommend using CommonJS for now, until they change that.

[avital]

If there's more to discuss, please post additional comments on a new GitHub issue thread.

[timothyarmes]

This issue with React is going to be a pain for a while I feel.

We can't use ReactLayout due to the fact that it' depends on the React package.
We can't use react-mounter since it's not compatible with FlowRouter SSR.

The there are a number of other useful packages that require the React package. For example, I use Meteor UserAccounts with their FlowRouting package; we can configure that to use the gwendall:blaze-to-react package to render the Blaze UserAccounts templates into our React layout. gwendall:blaze-to-react requires React.

It would be really useful if the React package did the right thing straight away...

[avital]

@dotansimha @newsiberian confirmed the source map issue. We'll look.

[ghost]

Does anyone have a workaround for this issue? Multiple Meteor packages seem to be getting this "Match" error with 1.3: Match error: Failed Match.OneOf or Match.Optional validation.

The issue seems to be caused by Babel's polyfil

Replication: Add any package that uses "Match" to meteor 1.3

[avital]

@Lenin7 Can you please file a new GitHub issue with a specific small repro?

[ghost]

Thanks @avital
The workaround for this is to remove babel's polyfill.

Also, it seems like @benjamn was already assigned to this issue last month:
https://github.com/meteor/meteor/issues/5712#issuecomment-169174327

[clayne11]

@timothyarmes I agree. The Meteor React package should start pointing at NPM as of now since that's the intended final behavior. It will make the migration much simpler.

[jamalx31]

I'm using angular with typescript. Now I get this error:
Uncaught ReferenceError: exports is not defined

[benjamn]

@jamalx31 try meteor add modules?

[jamalx31]

@benjamn Thanks that solved the issue. now I have this error
on client side on "import usersService from 'client/services/usersService';" I get:
Uncaught Error: Cannot find module 'client/services/usersService'

on server side on "import {Cards} from 'model/cards';" I get:
Error: Can't find npm module 'model/cards'. Did you forget to call 'Npm.depends' in package.js within the 'modules-runtime' package?

btw, in tsconfig.json I changed it to be:
"module": "commonjs",

[benjamn]

@dotansimha @newsiberian @avital the problems with setting breakpoints in Chrome seem to be limited to Chrome dev and canary (stable seems fine). Breakpoints also work fine in Firefox Nightly and Safari, and the line number comments that Meteor generates are all correct (though Babel doesn't always provide a mapping for every line).

As frustrating as it may be that Chrome has these problems, I'm not sure what we can or should change about our source maps to cater to its quirks.

Here are some other strategies that might help with your debugging:

• Insert the debugger statement in your source code to create reliable breakpoints. Wrap it with conditional statements as needed. Yes, this requires restarting the server, but the results are much more predictable.
• Turn off source maps in dev tools settings (under the ⚙ or ⋮ menu, or by pressing the F1 key). Fighting with buggy source maps might be a lot more trouble than simply stepping through the actual code. You can always refer to the line number comments in the right margin of the code to figure out what original source line you're looking at.
• Try debugging with Firefox Nightly or Safari, unless the problem is browser-specific.

[mordrax]

@benjamn That's a bit disappointing to hear but with workarounds, it should be ok.

• The debugger statement, with the 1.3 betas is not practical because of the ~10 sec reload times for a small app. Typically, finding a bug means setting breakpoints as you go. Meteor hot reload has made this strategy usable.
• Forgot I could turn off source maps. Brilliantly obvious idea!
• Above points are less effort than investing time in learning another set of devtools.

[trusktr]

@jamalx31 Try

import usersService from '/client/services/usersService'

with the leading slash (means root of your app). Does that work?

[jamalx31]

@trusktr I tried that, didn't help

[jamiter]

@jamalx31, if you are using TypeScript or JSX, you will have to add the extension:

import usersService from '/client/services/usersService.ts'

Only .js files do not require an extension.

[jamalx31]

@jamiter thank you so much, you are right, it needs the extension and as @trusktr said, the slash too

[jamalx31]

Another quick question:
now it's not possible to import less files ? like:
@import "/path/file.less"; (in main.less)

because I get error :
While minifying app stylesheet:
"client/styles/main.less" is not in the set.

[dagatsoin]

@jamalx31 non you can't. Less files are note exported as assets during the build time.

[jamalx31]

@dagatsoin thanks .. so what is the right way to use multi files ? put all of them in the "styles" dir ?

[pward123]

I'm not sure if this is the right way, but for my stylus files, I create a single index.import.styl file in the module that @imports all the other stylus files in the module. Then, I have a 'main.styl' file in my app's client folder that imports each module's index.

[helb]

@pward123: Yep, i do that too (just with Scss instead of Stylus). Not sure if it's the right or "clean" way either, for me it just feels as if i am trying to fool some "meteor magic" there… :confused:
Seems to work pretty well though.

[clayne11]

@pward123 and @helb: That's a pretty hacky and coupled way to set up your styles for your project.

I use SCSS but you can do this with any CSS preprocessor. I created a styles package and set up all of my variables and mixins in that package.

Then in each of my UI packages, I import my styles package and import my mixins and variables as I need them. Each package then just adds it's own styles for it's own views and components.

If I ever need to remove any packages / views, I simply remove the package and don't have to worry about touching multiple files or a main index file in order to do so. It's much looser coupling than what you guys are referring to and I think it works a lot better.

[dagatsoin]

@clayne11 have you managed to do some css modules with your workflow?

[clayne11]

I'm still on Meteor 1.2 as I'm running a pretty big production app so I'm not going to switch over to 1.3 until it's out of beta. I believe that CSS modules requires importing CSS files into your JS which you can't do with 1.2.

I'm definitely interested in trying it out, it looks like a great paradigm, but it'll have to wait.

[pward123]

@clayne11 unless I'm missing something, I don't believe css/scss/etc files located in node_modules will be automatically swept up and built into the bundle. So, to use your method, you'd have to continue using meteor packages with 1.3

[clayne11]

I didn't realize you were referring to node modules. With Meteor 1.3 are you able to import your CSS into your JS files? If so that's definitely the better solution to go with. That way your CSS is tied directly to the component that requires it and when you import the component to render somewhere it will bring its CSS along with it.

[pward123]

I'm assuming meteor 1.3 doesn't support css modules yet. I had no luck when I tried it a couple days ago.

Sent from my iPad

On Feb 17, 2016, at 7:14 AM, Curtis Layne [email protected] wrote:

I didn't realize you were referring to node modules. With Meteor 1.3 are you able to import your CSS into your JS files? If so that's definitely the better solution to go with. That way your CSS is tied directly to the component that requires it and when you import the component to render somewhere it will bring its CSS along with it.

—
Reply to this email directly or view it on GitHub.

[juliancwirko]

@pward123 , @clayne11 I think you can import css from node_modules as a static file which will be then bundled in global Meteor's css file. See: https://github.com/meteor/meteor/commit/12c946ee651a93725f243f790c7919de3d445a19

But there is still this problem with preprocessors: https://github.com/meteor/meteor/issues/6037

...correct me if i'm wrong

[dagatsoin]

@pward123 there is a project for css modules with 1.3 that I am using. It is still in beta but works well for basic cases (eg: you can't import vars with @import). https://github.com/nathantreid/meteor-css-modules (select the 1.3 branch)

[ghost]

To everyone considering importing CSS, check out
http://GitHub.com/jsstyles/JSS.

Importing CSS currently doesn't have a mechanism for cleanup, but with JSS,
you can clean up by detaching stylesheets when you're done using a
component.

Plus, with JSS you can use plain JavaScript functions and variables for
colors, dimensions, etc.

/#!/JoePea
On Feb 17, 2016 6:31 AM, "Daniel Neveux" [email protected] wrote:

@pward123 https://github.com/pward123 there is a project for css
modules with 1.3 that I am actually using. It is still in beta but works
well for basic cases (eg: you can't import a var files with @import
https://github.com/import).
https://github.com/nathantreid/meteor-css-modules (select the 1.3 branch)

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5788#issuecomment-185229324.

[trusktr]

And! Everything is namespaced, so you won't have name collisions.

(This is off-topic now though. Let's open new issues when we can.)

[pward123]

@markoshust I'm using a buildroot image (https://github.com/pward123/docker-tinymeteor/blob/release/v1.3.0/README.md) that's 14mb without any meteor app installed.

My CI is setup to run meteor build, then it volume mounts the bundle into a node:0.10.41 container to perform the npm install. Once that's done, the result is docker built using the tiny image.

edit: forgot to mention you can try the tiny image out using FROM ddipward/tinymeteor:1.3 in your dockerfile

[martijnwalraven]

A new 1.3 beta which combines modules, mobile, and testing is now available: https://github.com/meteor/meteor/issues/6266

[dagatsoin]

so should we close this issue and the cordova one and continue on 6266?

[martijnwalraven]

Yes, let's close this! But I also think it would be better to have people open new issues from now on instead of commenting on a thread, because that makes it harder to keep track of whether some concern has been addressed.

[newsiberian]

Hello, guys, could you please check this. I have app crushes after updating to beta-11.

[martinwh99]

I'm using Elemental UI with Meteor 1.3. beta 11. I had no problem in 1.2 and WebPack but when i try to import elemental.less i get:

Uncaught Error: Cannot find module './../../../node_modules/elemental/less/elemental.less'

same with css files i try to import.

am i missing something?

[d-winter]

Hi, using react-autoform-material-ui with 1.3 beta 11 I get the following error.
Any tips? I really need to implement a feature using this package soon....

=> Started proxy.
=> Started MongoDB.

TypeError: Arguments to path.join must be strings
at path.js:360:15
at Array.filter (native)
at Object.exports.join (path.js:358:36)
at /Users/me/.meteor/packages/meteor-tool/.1.1.13-beta.11.uoh1tu++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/static-assets/server/mini-files.js:86:16
at /tools/isobuild/import-scanner.js:87:23
at Array.forEach (native)
at ImportScanner.addInputFiles (/tools/isobuild/import-scanner.js:86:11)
at /tools/isobuild/compiler-plugin.js:691:15
at Array.forEach (native)
at Function.computeJsOutputFilesMap (/tools/isobuild/compiler-plugin.js:672:19)
at ClientTarget.emitResources (/tools/isobuild/bundler.js:749:8)
at /tools/isobuild/bundler.js:516:12
at /tools/utils/buildmessage.js:359:18
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:352:34
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:350:23
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at Object.enterJob (/tools/utils/buildmessage.js:324:26)
at ClientTarget.make (/tools/isobuild/bundler.js:507:18)
at /tools/isobuild/bundler.js:2232:14
at /tools/isobuild/bundler.js:2322:20
at Array.forEach (native)
at Function..each._.forEach (/Users/me/.meteor/packages/meteor-tool/.1.1.13-beta.11.uoh1tu++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
at /tools/isobuild/bundler.js:2321:7
at /tools/utils/buildmessage.js:271:13
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:264:29
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:262:18
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:253:23
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at Object.capture (/tools/utils/buildmessage.js:252:19)
at Object.exports.bundle (/tools/isobuild/bundler.js:2213:31)
at /tools/runners/run-app.js:586:36
at Function.run (/tools/tool-env/profile.js:489:12)
at bundleApp (/tools/runners/run-app.js:576:34)
at AppRunner._runOnce (/tools/runners/run-app.js:629:35)
at AppRunner._fiber (/tools/runners/run-app.js:881:28)
at /tools/runners/run-app.js:406:12

[jedwards1211]

@clayne11 @pward123 I just wanted to remind everyone that importing CSS, Less, Sass, etc. from JS files is possible if you use Webpack with Meteor, plus you get a whole host of other benefits like automatic code splitting, and the ability to customize practically anything in the compilation process.

[clayne11]

I'm well aware. I will likely be switching my project to webpack because frankly the Meteor build system is just not keeping up at all.

I can't deal with 20-30s code reloads when they could be 1-2s. It's costing me a lot of productivity.

[shawnmclean]

Along with these AMD changes, is there a way to tell the build system to ignore certain imports?

For eg. I have redux-devtools which I want to only import in dev environment. Code like this does not work:

if(Meteor.settings.public.environment == 'development'){
  import DevTools from 'redux-devtools'
}

But something like such as if(__DEV__){ } works with a webpack config.

[jedwards1211]

@shawnmclean since import statements have to be top-level, I think you should clarify what you mean about what works with Webpack config. With Webpack 1 one has to use require inside of if statements instead of import:

let DevTools;
if (__DEV__) {
  DevTools = require('redux-devtools').default; // .default necessary since Babel 6
}

Or with Webpack 2 one can use System.import, but that does trigger automatic code splitting:

let DevTools;
if (__DEV__) {
  DevTools = System.import('redux-devtools');
}

Also note that if (Meteor.settings.public.environment === 'development') can also be used with Webpack, you just need the following plugin config:

  new webpack.DefinePlugin({
    'Meteor.settings.public.environment': JSON.stringify('development')
  })

[benjamn]

@jedwards1211 note that System.import('redux-devtools') returns a Promise for the DevTools object, not the object itself