How to migrating from "All-In-Packages" to 1.3 modules?

help
1

Hi guys,

is there a migration tutorial on how to “best-practise migrate” from an “All-In-Packages” structure to 1.3 modules?

Right now my app heavily uses “All-In-Packages” and I guess it is time to make the switch (as Meteor guide recons) :slight_smile:

Kind regards
Barty

1 Like
2

You could take a look at the todos app which uses 1.3 modules and is based on the guide or the mantra blog example for reference

It basically boils down to:

  • move your folders in your ‘packages’ folder to /imports (or /client/modules in mantra)
  • rename the package.js files to index.js, remove the Package.describe/Package.onUse stuff and convert api.use/api.addFiles to the import syntax
  • import previously-global variables in your package files

e.g.

// index.js

api.use('meteor'); 
// becomes
import {Meteor} from 'meteor/meteor';

api.addFiles('file.js');
// becomes
import 'file.js';
4 Likes
3

This is a great list of things! would you mind contributing it to the migrating to 1.3 section of the guide?

4

It would be really nice for someone to provide a best-practices for a microservice-type architecture. I’m also using the All-In-Packages–>Umbrella Packages style architecture in 1.2 in an app that is split up into around 10 microservices that all share some code and am struggling a bit with how to migrate to the new modules system. My current structure is like this:

microservice-1
—.meteor
—/packages -> simlink to …/packages
microservice-1
—.meteor
—/packages -> simlink to …/packages
packages
—app:package
—app:package2
—…

The ToDo example has been helpful in how to structure a small app. But what are the recommendations for building out a larger app with multiple services? Do I put everything in the /imports folder then just use an index.js in each microservice to import the required components? Or do I need to put one in /client and /service for each microservice? Also, how do I handle NPM imports. Do I only need to run npm install module --save once or once for each app? Advice appreciated.
Thanks!

1 Like
5

@reoh: thanks man - thats a great starting point!

In “all-in-packages” I had a “packages/lib” loading all the “related meteor+third-party packages”, p.e. like

  var packages = [
    'meteor-base@1.0.1',             // Packages every Meteor app needs to have
    'mobile-experience@1.0.1',       // Packages for a great mobile UX
    'mongo@1.1.2',                   // The database Meteor supports right now
     // ....

PLUS in .meteor/packages I was only loading my own CORE Package that bundled it all together. Playing around with 1.3 a bit I found that I seem to definetly need some meteor-base-packages listed in .meteor/packages - just like in the example todos app.

What do you guys recon for adding those packages? Shall I simply use meteor add aldeed:simple-schema instead, meaning that I get all the advantages of being able to do a simple meteor list or meteor update?

6

Yep - that’s one of the biggest benefits of the module approach over packages - you don’t have to mess around with package.js files for most apps anymore.

7

Ok - I see! :slight_smile:

Is this the correct way to hardcode package versions for git version-control?

  1. indicate the package version within /.meteor/packages, p.e. like aldeed:simple-schema@=1.5.2
  2. Commit to git
  3. … after a while: Run meteor list to check for updates. If you want to upgrade, manually edit /.meteor/packages, p.e. like aldeed:simple-schema@=1.5.3

Advantages
Retrace updates in your version-control and easily rollback when needed

Disadvantages
Do we loose the meteor update-intelligence when doing this?

8

Nono! Meteor automatically does this for you with .meteor/versions. So whenever you clone and run your project, Meteor will pick the same numbers as before! Unless you use meteor update which updates the packages in your project.

9

bumper! :stuck_out_tongue_winking_eye: seems like all those month in “all-in-packages” have killed my basic understanding of meteor update. Thanks for bringing it back!

1 Like
10

2 more questions for you guys:

  1. Where are npm package-versions tracked?
  2. What to do with fixtures (that before had debugOnly: true in their package.js).
    I’d like to run those fixtures in development mode, but NOT in production. Is there a flag to check against, like
if (Meteor.isDebugOnly) {
  require ('fixture.js')
}

?

11

  1. I don’t think npm versions are tracked outside of the root package.json

  2. Meteor.isDevelopment was also added in 1.3 :wink:

@sashko PR submitted!

2 Likes
12

What do you mean by this term? I’m new to the Meteor 1.3 import stuff, but have a lot of traditional (local) packages.

13

He’s referring to the “packages for everything” approach that some developers leverage, to get certain benefits (a lot of which are no longer relevant with 1.3). See item 4 of Building-Large-Apps-Tips for more details.

1 Like
14

check this one out http://www.telescopeapp.org/blog/telescope-package-based-architecture/

15

Thanks for the hint - I had wiped away my package.json or it did not exist. In order to recover it I removed my node_modules directory and reinstalled the node-packages via meteor npm install --save jquery html-to-textmeteor npm install --save *

16

Thats cool - is it undocumented? I can’t find it in http://docs.meteor.com/#/full/meteorguide ?

17

Hmm - it is missing in the docs. I’ve submitted a PR.

2 Likes
18

There’s also Meteor.isProduction btw, they were mentioned in the changelog - https://github.com/meteor/meteor/blob/master/History.md

2 Likes
19

Thats cool and good to know!! :slight_smile:

20

Anyone else having to do this, too: one of the first steps should be to put your 3rd party and meteor packages-imports out of you “lib”-packge into ./meteor/packages. check the according package versions within .meteor/versions.

PLUS (if using npm packages) make sure that a package.json) exists (see this topic above)

1 Like