Meteor-package-import - a convenient way to import Meteor packages into npm packages

announce
1

If you’re building npm packages for use with Meteor, here’s a way to import Meteor packages into npm packages using the Meteor import syntax. By using meteor-package-import in combination with babel-plugin-replace-require, you can import Meteor packages just like when developing with Meteor:

import { Meteor } from 'meteor/meteor';

The babel-plugin-replace-require plugin, in combination with a babel preset that enables the use of import statements, will convert this into a call to meteor-package-import:

var _meteor = require('meteor-package-import')("meteor");

You can enable this with the following babel config:

  "plugins": [
    [
      "babel-plugin-replace-require",
      {
        "meteor": "require('meteor-package-import')"
      }
    ]
  ]

You can find the package here: https://www.npmjs.com/package/meteor-package-import

Note: at this time, meteor-package-import does not automatically install missing Meteor packages for you, although it will display an error if the package isn’t found.

8 Likes
2

Does this mean that such problem can be resolve with this package ?

3

It won’t solve the issue of being unable to import Meteor packages from a standard node app, but the approach I’m using with babel-plugin-replace-require is similar to the possible workaround discussed at the end of that issue.
I use my meteor-package-import package to facilitate writing NPM packages that I load into my Meteor app. I should put up a sample sometime soon.

1 Like
4

Why not just use an atmosphere package for Meteor packages? If you do that you can even gain the benefits of the modern bundle split.

5

There’s a few main reasons for me:

  1. Testing. I find npm packages easier to test with jest. I like my unit tests to run very quickly, and I require the ability to run them from my IDE. I could probably do something similar with Meteor packages, but I’d have to set up the package.json and babel build steps etc so there’d be a lot of duplicated work, and I’m not sure how I feel about the idea of my tests using a different compilation process (@babel/cli) vs the compiled code (meteor).
  2. TypeScript. I use TypeScript and Meteor packages written with TypeScript don’t export the typings.
  3. Private packages. At work we have a number of Meteor-specific npm packages that are kept on our private npm server. With Meteor packages there is no way to keep a shared package private unless you duplicate the code into each app or configure the Meteor package directory to point to a shared location. In either case, each app will end up building their own version of the package, which in my experience slows down build times considerably. With the shared packages directory you also lose control over which version your app uses and I prefer my packages to be locked at a specific version for consistency. git submodules could probably help there, but in my experience they are a pain to work with (especially on Windows) and are nowhere near as simple for installs and updates.
  4. Constraint solving. Numerous times now, I’ve had to fork abandoned Atmosphere packages and make updates to their code because the version of a package they require is incompatible with the version that is required by the latest Meteor update. With npm packages that is never an issue since npm packages are allowed to have different versions of dependencies.

Because of these reasons, I write Atmosphere packages for build plugins only. All of my other packages use npm.

1 Like
6

Those are good reasons. All of that speaks to a need for a meteor source entry in npm packages - then we can get the modern bundles, and easy meteor package imports without having to precompile packages. I don’t remember what the reason is for not having that, but I do remember there is one.

1 Like