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! 👍

[fakenickels]

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

[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]

👍

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

   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.

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

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

   we can write

   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

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

   without the leading slash.

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

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

   Now we can do

   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 👍

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'

[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… 😕
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 notifications@github.com 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: 12c946e

But there is still this problem with preprocessors: #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" notifications@github.com 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
#5788 (comment).

[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: #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