Are there any 1.3 boilerplates like the kickstarts for webpack?
2 Likes
+1.
I’m trying to work out whether I can npm install browserify or do I still have to use cosmos:browserify. Github issues https://github.com/meteor/meteor/issues/5795 and https://github.com/meteor/meteor/issues/5825 do not present any obvious answers.
EDIT: Actually, I just got it working without having to touch browserify at all… Not sure if I’m doing it right but that was the last step in my port to 1.3! Loving the speedy build although my app is still pretty small.
I wouldn’t call my project a boilerplate or even a clean project (after the multiple refactors in the last month) but at least it’s finally running on 1.3 with a bit of react/redux sprinkled on and I can move on to actually adding content! YAYAYA!!
If you have the redux chrome extension, you can see Tracker updating the store with meteor subscription data (on game creation) as it comes back to minimongo . This way, I keep all client state in the store, propagate any updates to components via props thus keeping them pure and easy to unit test.
We’re hopefully going to launch something like this with the Meteor Guide alongside 1.3.
I’d like to reiterate a question that was asked earlier - how will this work with importing the same NPM package in multiple Meteor packages? Will the dependency tree be managed to ensure only one copy of each library is included?
@clayne Great question, and thanks for reiterating it. My current plan (slightly different from what’s implemented in the latest beta release) is that the top-level node_modules/ directory in an app will provide importable packages not only for application code but also for Meteor packages. In other words, the app gets to decide which version of an npm package will be used throughout the app and its packages. Packages can still use Npm.depends to install their own local dependencies, but they can also import or require npm dependencies that they did not explicitly install, with the expectation that the application will provide those dependencies.
So, to answer your question: no, the dependency tree will not be managed by Meteor, and there will be no special enforcement of single installation, but it should be straightforward for the app to provide a single version of a common dependency.
This will work alright in the case of a package that I write myself, but what about if I want to release a package on Atmosphere?
Will there be a way to tell the compiler that a certain package is required as a top-level NPM package, or to have something like a weak Npm.depends such that if the if the NPM package is included at the top level, it doesn’t get included, otherwise it does?
@clayne I think these questions deserve their own forum thread, if you wouldn’t mind starting a new topic. I have some ideas, and I’m sure you do too, but I don’t want this discussion getting lost in the larger 1.3 announcement thread.
Yes, that would definitely cause problems. How does this package work without a main field or an index.js file?
Hey folks, as of today I’m getting back to work after some holiday downtime, and I’m hoping to spend this week responding to all the feedback and ideas above. Thanks for all the input, and for your patience!
This thread has gotten rather long, so if there’s something I don’t respond to in the next few days, don’t hesitate to resurface it. If it feels like a distinct topic, starting a new thread might be a good idea. Just @mention me and link back to the original post(s).
7 Likes
Yep, that’s the plan for 1.3: you have complete control over the contents of node_modules directories in your app, and Meteor will bundle those modules into your app when you deploy.
Future releases may introduce new features that help with managing npm dependencies, but we believe that can wait until after 1.3.
Created a new thread:
Cool stuff. Two package managers feels so dirty, but hopefully this will work out.
I don’t know what the deal is, but the imports/ directory thing is definitely not working for me. Maybe I’m just stupid. Tried /imports/, /server/imports/, /client/imports/, but files in those folders still get eager-loaded.
But I like this. It’s better than I expected. Well done.
Seems like this commit fixes it. Running Meteor from the latest checkout and now files in imports/ are not eagerly loaded 
3 Likes
yep. there are loading always. May be @benjamn’s meaning of lazy evaluation is something else.
Anyway, they are modules so I don’t care whether they load or not. So, I simply ignore using imports and use regular files as usually and import as needed.
1 Like
No, this was a bug, but will be fixed in the next beta.
1 Like
So, I’ve probably missed a lot of discussion on 1.3.
What’s the plan with Atmosphere/Meteor packages?
Here’s my situation:
- Can’t use just NPM modules since most Meteor-centric things are in Meteor packages.
- Don’t want to use just Meteor packages since NPM modules are more up-to-date.
- Sharing code between your apps is harder, since for that you still need Meteor packages (can’t claim dependencies in modules and sharing the same
packagesfile between all the apps would not be a good solution).
Essentially, packaging in Meteor is not simple anymore. You have to mix and match things. I don’t find that very good. Is MDG planning on doing something about this?
I feel like Meteor has been almost unusable as a development environment for me ever since the 1.2 release. I kept hoping 1.3 was just around the corner yet it never seems to arrive. So… has anyone got a time estimate on when this release will finally drop?
maybe this can give you a sense of the direction it is going
3 Likes
are you using either:
- meteor create/update --release 1.3-modules-beta.*
- git clone/checkout/pull meteor from git branch release-1.3
if you want to advance, that’s the way to go. (and you can track the commits and issues step by step)
works for me.