I think we can still try just using npm init then just do npm install --save modules… 
ok, so we can use it normally? With package.json in the root folder etc? I tought that this a custom npm solution which is similar 
If we can do it in a standard way this is even better.
I might test it out tonight though… I am also trying to figure out how to export Template.Main.helpers({}) if I used packages or how to import html files if I use api.mainModules
Using it with Blaze could be problematic I’ve tested it with imports folder and main.js file structure and it works well. I wonder if we can test it with Meteor-React package.
@benjamn what’s the situation with the current implicit load order and the imports?
Does one take precedence over the other, does implicit load order get ignored if there are imports?
It seems it will really work well with React then given that html and js goes inside jsx file. Sigh
Yes, like a Blaze package… Oups, bad example, this will be gone too 
Actually, i would not really miss Atmosphere, we could probably have specific meteor packages on npm.
1 Like
Me neither, but I’d certainly like a meteor update to be able to go fetch newer versions of the included npm packages…
2 Likes
Packages with Blaze dependencies can stay on Atmosphere and I think it’s ok (of course not the pure wrappers). Also packages with other Meteor parts, Collections, Tracker etc. They still can include Npm parts which could be also used separately. Blaze is a great tool for prototyping and small apps or MVP projects. I hope that Blaze will stay with Meteor too. Imagine that you need to show a quick prototype to your client. You’ll just meteor add ... some Blaze related packages and you’re ready to go. Then you could build the project with React etc.
Great. Thanks a lot!
From my testing it seems that the implicit load order takes first precedence but if you need a file to load earlier than normal you can use an import '../foo'; and it will ensure that file is loaded before.
2 Likes
implicit load order takes first precedence but if you need a file to load earlier than normal you can use an import
@SkinnyGeek1010 @benjamn so basically this makes ES2015 imports in Meteor a “glorified override”, no?
I’m not trynig to kneejerk this or underrate it, but I think we do have a clear problem here. It is an odd choice to mix file loading strategies, is it not?
I think the mixed loading strategy will work well for current apps that would be hard to completely migrate the normal way. However, for new apps i think it makes sense to have two entry points by some convention, and then you could have file loading by the node spec.
However I agree, if the default way for new apps isn’t the ‘JavaScript’ way we’ll have a big problem.
3 Likes
I disagree. As long as Meteor supports what you call the ‘Javascript’ way for those of us who need it, the starting point for newbies should be as easy as possible: globals and autoimports.
People starting with Meteor doesn’t always come from the node world or has ever written a single line of Javascript.
If ‘autoimport’ is that bad practice (which I don’t think it is, look at the meteor apps running in production right now), instead of the package ‘modules’ create a package ‘autoimport’ and suggest its removal once the app gets serious, just like you are already doing with ‘insecure’ and ‘autopublish’.
13 Likes
instead of the package ‘modules’ create a package ‘autoimport’ and suggest its removal once the app gets serious, just like you are already doing with ‘insecure’ and ‘autopublish’
@luisherranz yes that perhaps would be the best possible way to address this in terms of consistency and a meteor mental model
1 Like
In theory I agree. If you could just count on the global that you want to be defined that would be great. However, a lot of times it’s not and beginners struggle with load order folders and prepending A-Z to a filename.
If one was starting from scratch and you had to explain how to use their new module it seems much easier to teach them to follow one rule… if you need module X in this file, then import module X like this: import 'client/utils/foo'. Done. End of story. The current folder/file load order takes an entire page to explain.
This is even more important when using views other than Blaze because they don’t have the Meteor.startup built in and a lot of things are undefined.
Anyone having any issues using this import statement in a .jsx file?
W20151212-20:49:50.362(-6)? (STDERR) import moment from "moment";
W20151212-20:49:50.362(-6)? (STDERR) ^^^^^^
W20151212-20:49:50.363(-6)? (STDERR) SyntaxError: Unexpected reserved word
W20151212-20:49:50.363(-6)? (STDERR) at C:\Users\Jeremy\Documents\webdevelopment\Meteor\test\.meteor\local\build\programs\server\boot.js:241:30
W20151212-20:49:50.363(-6)? (STDERR) at Array.forEach (native)
W20151212-20:49:50.363(-6)? (STDERR) at Function._.each._.forEach (C:\Users\Jeremy\AppData\Local\.meteor\packages\meteor-tool\1.1.11-modules.0\mt-os.windows.x86_32\dev_bundle\server-lib\node_modules\underscore\underscore.js:79:11)
W20151212-20:49:50.363(-6)? (STDERR) at C:\Users\Jeremy\Documents\webdevelopment\Meteor\test\.meteor\local\build\programs\server\boot.js:137:5
If I rename the file to .js everything works fine.
3 Likes
I was having the same issue as yours earlier while trying to import the npm installed React in a .jsx file inside the client/imports folder.
As a temporary workaround, I tried to convert all the jsx into vanilla javascript so I could rename the file to normal .js.
But then I saw another error in my browser
Uncaught ReferenceError: process is not defined
I think this error is most probably caused by the npm installed React because when I try other npm package like marked and moment everything works fine.
Does this update mean Blaze will gain incremental loading?
1 Like