New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
avital opened this Issue Dec 12, 2015 · 221 comments

Comments

Projects
None yet
@avital
Contributor

avital commented Dec 12, 2015

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.

@avital avital added this to the Release 1.3 milestone Dec 12, 2015

@avital avital changed the title from 1.3 beta release (ES2015 modules, better file load order control, and more) to Meteor 1.3 *early beta* (ES2015 modules, better file load order control, and more) Dec 12, 2015

@guilhermedecampo

This comment has been minimized.

Show comment
Hide comment
@guilhermedecampo

guilhermedecampo Dec 12, 2015

Thanks for that! Looking forward to test modules! 👍

guilhermedecampo commented Dec 12, 2015

Thanks for that! Looking forward to test modules! 👍

@grsabreu

This comment has been minimized.

Show comment
Hide comment
@grsabreu

grsabreu Dec 12, 2015

Contributor

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

Contributor

grsabreu commented Dec 12, 2015

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

@vjau

This comment has been minimized.

Show comment
Hide comment
@vjau

vjau Dec 12, 2015

Contributor

This seems to work great, thank you mdg.

Contributor

vjau commented Dec 12, 2015

This seems to work great, thank you mdg.

@nicolasparada

This comment has been minimized.

Show comment
Hide comment
@nicolasparada

nicolasparada commented Dec 12, 2015

Nice.

@GeoffreyBooth

This comment has been minimized.

Show comment
Hide comment
@GeoffreyBooth

GeoffreyBooth Dec 13, 2015

Contributor

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.

Contributor

GeoffreyBooth commented Dec 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ciwolsey

ciwolsey Dec 13, 2015

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

ciwolsey commented Dec 13, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 14, 2015

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

ccorcos commented Dec 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Dec 14, 2015

Member

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

Member

benjamn commented Dec 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 14, 2015

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

ccorcos commented Dec 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@raix

raix Dec 14, 2015

Contributor

👍

Contributor

raix commented Dec 14, 2015

👍

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Dec 14, 2015

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.

TankOs commented Dec 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 15, 2015

Contributor

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

Contributor

trusktr commented Dec 15, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 15, 2015

Contributor

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

Contributor

trusktr commented Dec 15, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 15, 2015

Contributor

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

Contributor

trusktr commented Dec 15, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Dec 15, 2015

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

TankOs commented Dec 15, 2015

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

@ccorcos

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 15, 2015

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

ccorcos commented Dec 15, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 15, 2015

Contributor

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

Contributor

trusktr commented Dec 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 15, 2015

Contributor

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'

?

Contributor

trusktr commented Dec 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 16, 2015

What if it were just the name of your package?

ccorcos commented Dec 16, 2015

What if it were just the name of your package?

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Dec 16, 2015

Contributor

Then that's what it would be! ;]

Contributor

trusktr commented Dec 16, 2015

Then that's what it would be! ;]

@GeoffreyBooth

This comment has been minimized.

Show comment
Hide comment
@GeoffreyBooth

GeoffreyBooth Dec 16, 2015

Contributor

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

Contributor

GeoffreyBooth commented Dec 16, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@lydell

lydell Dec 16, 2015

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.

lydell commented Dec 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alubbe

alubbe Dec 16, 2015

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.

alubbe commented Dec 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@prodogs

prodogs Dec 16, 2015

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

prodogs commented Dec 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 17, 2015

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

ccorcos commented Dec 17, 2015

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

@prodogs

This comment has been minimized.

Show comment
Hide comment
@prodogs

prodogs Dec 17, 2015

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

prodogs commented Dec 17, 2015

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

@JeremyBYU

This comment has been minimized.

Show comment
Hide comment
@JeremyBYU

JeremyBYU Dec 17, 2015

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?

JeremyBYU commented Dec 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ccorcos

ccorcos Dec 17, 2015

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'

ccorcos commented Dec 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@helb

helb Feb 16, 2016

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

helb commented Feb 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@clayne11

clayne11 Feb 16, 2016

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

clayne11 commented Feb 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dagatsoin

dagatsoin Feb 16, 2016

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

dagatsoin commented Feb 16, 2016

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

@clayne11

This comment has been minimized.

Show comment
Hide comment
@clayne11

clayne11 Feb 16, 2016

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.

clayne11 commented Feb 16, 2016

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.

@dcsan dcsan referenced this issue Feb 17, 2016

Closed

Porting to 1.3 #2254

@pward123

This comment has been minimized.

Show comment
Hide comment
@pward123

pward123 Feb 17, 2016

@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

pward123 commented Feb 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@clayne11

clayne11 Feb 17, 2016

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.

clayne11 commented Feb 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pward123

pward123 Feb 17, 2016

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.

pward123 commented Feb 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@juliancwirko

juliancwirko Feb 17, 2016

@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

juliancwirko commented Feb 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dagatsoin

dagatsoin Feb 17, 2016

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

dagatsoin commented Feb 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 17, 2016

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

ghost commented Feb 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Feb 17, 2016

Contributor

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

Contributor

trusktr commented Feb 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pward123

pward123 Feb 18, 2016

@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

pward123 commented Feb 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@martijnwalraven

martijnwalraven Feb 19, 2016

Contributor

A new 1.3 beta which combines modules, mobile, and testing is now available: #6266

Contributor

martijnwalraven commented Feb 19, 2016

A new 1.3 beta which combines modules, mobile, and testing is now available: #6266

@dagatsoin

This comment has been minimized.

Show comment
Hide comment
@dagatsoin

dagatsoin Feb 19, 2016

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

dagatsoin commented Feb 19, 2016

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

@martijnwalraven

This comment has been minimized.

Show comment
Hide comment
@martijnwalraven

martijnwalraven Feb 19, 2016

Contributor

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.

Contributor

martijnwalraven commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@newsiberian

newsiberian Feb 21, 2016

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

newsiberian commented Feb 21, 2016

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

@martinwh99

This comment has been minimized.

Show comment
Hide comment
@martinwh99

martinwh99 Feb 23, 2016

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?

martinwh99 commented Feb 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@d-winter

d-winter Feb 29, 2016

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

d-winter commented Feb 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jedwards1211

jedwards1211 Mar 13, 2016

Contributor

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

Contributor

jedwards1211 commented Mar 13, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@clayne11

clayne11 Mar 13, 2016

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.

clayne11 commented Mar 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shawnmclean

shawnmclean Mar 17, 2016

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.

shawnmclean commented Mar 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jedwards1211

jedwards1211 Mar 17, 2016

Contributor

@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')
  })
Contributor

jedwards1211 commented Mar 17, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Mar 17, 2016

Member

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

Member

benjamn commented Mar 17, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment