Deprecate or rewrite packages, examples, and documentation to take advantage of modules support in Meteor 1.3

[benjamn]

• [x] The jsx package will no longer be necessary: https://github.com/meteor/meteor/commit/86b743f96346b66a7b79586823bbb92eeed8a83d
• [x] Users should npm install react in a local node_modules directory rather than using the wrapper react package from this repository.
• [ ] The react-meteor-data and react-template-helper packages might as well become npm packages, too.
• [ ] The examples should be rewritten with appropriate package.json files.
• [x] The docs can be drastically simplified, especially https://github.com/meteor/react-packages/blob/devel/docs/client-npm.md.

[yyx990803]

Awesome, thanks for laying this out Ben. I might work on some of these next week, but most likely not with a full workload. Definitely hope to get this done first thing after the holidays.

[stubailo]

The react-meteor-data and react-template-helper packages might as well become npm packages, too.

How do we make them use/depend on Blaze/Tracker, then?

[benjamn]

They can do import {Tracker} from "tracker", or the CommonJS equivalent, and that "tracker" will be resolved to a Meteor package.

[jperl]

They can do import {Tracker} from "tracker", or the CommonJS equivalent, and that "tracker" will be resolved to a Meteor package.

Does that mean we can start publishing meteor packages to npm even if they depend on meteor packages?

---

EDIT just saw this comment -- so it appears that is the case. Very exciting!

[benjamn]

Per recent discussions with the team, the syntax is probably going to end up looking like import {Tracker} from "meteor/tracker" (note the extra meteor/). The primary reason for this change is that it's much easier to avoid collisions with npm package names if all Meteor packages are namespaced. Indeed, the only possible conflict is with https://www.npmjs.com/package/meteor, which is a wrapper package for Meteor itself, and thus unlikely to be installed within a Meteor application.

The reason we were worried about conflicting package names is that we're also getting rid of the top-level app directory, which means an app with a top-level node_modules directory will actually share that node_modules directory with Meteor packages. Since the app developer could install any npm package in the node_modules directory (and since npm 3 often hoists deeper dependencies up to the top level), we think it's pretty important to prevent Meteor packages from competing with npm packages over the top-level node_modules namespace.

Here's what the directory structure might look like in an example app:

meteorInstall({
  "example.css": ...,
  "example.html": ...,
  "example.js": function(require, exports, module) {
    // This works, as long as the app developer has installed some version of React.
    var React = require("react");
    // These imports work according to the usual Node module lookup algorithm.
    var Accounts = require("meteor/accounts-base").Accounts;
    var Blaze = require("meteor/blaze");
    ...
  },
  node_modules: {
    // This copy of react was presumably installed by the app developer
    // in the top-level node_modules directory within the app, by simply
    // running `mkdir node_modules; npm install react`. However, because
    // this node_modules directory is shared between app code and
    // Meteor package code, both apps and packages can import this
    // copy of React. In other words, the app developer gets to decide
    // which version of React should be used throughout the application.
    react: {
      "package.json": ...,
      "index.js": ...,
      ...
    },
    // All Meteor packages get meteorInstall-ed inside node_modules/meteor/,
    // regardless of whether they were local packages or came from Atmosphere.
    meteor: {
      "accounts-base.js": function (require, exports, module) {
        // This works, as long as the app developer has installed some version of React.
        var React = require("react");
        ...
      },
      "blaze.js": function (require, exports, module) {
        // Meteor packages that don't yet api.use("modules") will have stubs
        // generated for them, so that modules-using code can still import them.
        module.exports = Package["blaze"];
      }
    }
  }
});

[eXon]

@benjamn Hey Benjamin. Collision with NPM packages and Meteor could be easily avoided if the exports were cleaned on 1.3 don't you think? This seems to be a problem that is specific to core packages and it would be a shame to make every Atmosphere package work the same way.

With Webpack, I've been using NPM package and then fallback on Meteor package exports only if they don't exist and it seems to work quite well. If we clean all the export Meteor has (we could easily stay retro-compatible for a while).

I feel like this would be much better to transform the Tracker export as MeteorTracker:

import Tracker from 'meteor-tracker';
// or...
import {Tracker} from 'meteor-tracker';

And maybe latter they will really be on NPM ;) This would be WAY WAY less weird for newcomers. What do you think?

PS. Sorry for posting this here. I haven't found the discussion on the Meteor repo.

[Mokto]

Any update on this ? ;)

[filipenevola]

I'm closing this just because it's too old. We can open new issues for items that are still valid.

Most of these items were solved already or replaced by new strategies (like hooks)