Documentation for how to migrate an existing project about meteor-webpack-react

[AdamBrodzinski]

Thanks for the input! I'm actually working on guides right now 😄 Currently the readme kind of assumes some prior webpack & ES6 knowledge. I'm hoping to fill the gaps with several guides covering various topics (how it works, migrating current apps, ).

I've started a screencast but it's more less a rough draft and doesn't mention using meteor packages (which are just installed like normal).

https://www.youtube.com/watch?v=QpixFzvf8U8

There's also some forum posts here that may provide context: https://forums.meteor.com/t/meteor-webpack-es6-modules-hot-code-patching-fixes-load-order-more/9110

Even just adding a paragraph saying "Make a copy of the entire directory structure, delete the contents of /app and put your own stuff in there" would help, if that is indeed correct.

One thing to note is that files are not executed until they're imported the first time. If they're never imported they won't be bundled (helping remove dead code). If you just drop your app into app/ nothing will happen until the file is imported.

I recently migrated an app and the gist for my method was to drop the old app into the root and rename to old_app and then overwrite the old .meteor with the new one. Then start in main.client.js and import/add the router. The router will essentially be the entry point for most apps. I commented out all but the root route and then fixed undefined errors but adding in the file and importing it. Eventually the route will work without undefined errors. Then keep going route by route until that's done. You'll have some files that are not erroring out (the ones left over) and those can be dropped in (and add exports of course).

[orlade]

Thanks! That alone explains a lot, and the forum and that video are really great. I particularly appreciate you pointing out the things that don't work 👍

I'm pretty much sold on this solution, but definitely the scariest part is that it's not "official" so it's a business risk. You mentioned in the forum that you can just drop sources into meteor_core, which is important to know. In particular, we've got a pretty large dependency on Autoform so "legacy" Blaze examples are important too (for now at least). It sounds like you've got it covered, though.

Hopefully I'll get to play with this a bit next week and give some more actionable feedback. Watching that video felt a bit like seeing the early Meteor demos for the first time. Exciting stuff!

[AdamBrodzinski]

Yep it's a bit of a leap to migrate especially since it's not official but what comforts me is at the end of the day you're just dropping client.app.js into the meteor folder and then meteor takes care of the rest.

I also have some legacy blaze (data-tables) that gets inserted into a jsx shell.

I'll post back here once I get some of the guides filled out (prob tomoroow, my fingers are killing me lol).

[jedwards1211]

@AdamBrodzinski I'm going to add you as a collaborator, since you're putting at least as much effort into this as I am these days :)

[jedwards1211]

@orlade CoffeeScript can be used if you add coffee-loader. Maybe you'd be better off keeping the existing code in meteor_core and writing new stuff as webpack modules...it's just a matter of how much refactoring you want to do, because there's no automated way to turn the package globals into module exports and requires that I know of.

[orlade]

@jedwards1211 Thanks for the advice. I've been experimenting with ways of defining packages that are valid in both Meteor and npm, with lots of ugly syntax like module?.exports = ... and if require? then SomeGlobal = require('node/module'). It kind of almost works, but it's tiring to even think about, and the builds are slow anyway.

Using meteor_core for everything sounds like a good place to start. We'll give it a shot.

[AdamBrodzinski]

@orlade the best thing I can think of to be able to require a package is to fake it by doing something like this. At least you have a path to variable and it gives some documentation to the file.

// packages.js

/* global  Meteor, SimpleSchema, FlowRouter */
export const Meteor = Meteor;
export const SimpleSchema = SimpleSchema;
export const FlowRouter = FlowRouter;


// somewhere else

import FlowRouter from '../../packages/FlowRouter';
// or with an alias
import FlowRouter from 'packages/FlowRouter';

Also i'm in the same boat as Andy.... I really try to stay away from Meteor packages unless it's something to augment core. I've had too many issues with bugs and lack of maintainability. Using React makes this even easier because everything is on NPM. I tend to use Meteor as a package to handle DDP, Auth, and pub/sub for mongo.

Using meteor_core for legacy is do-able. I'm doing this for a few files (especially styles).

@jedwards1211

@AdamBrodzinski I'm going to add you as a collaborator, since you're putting at least as much effort into this as I am these days :)

Thanks! 🍻

[AdamBrodzinski]

Closing this out, it would be great if someone wrote a guide in the wiki for migrating apps.