Meteor 1.3 here and now it's time to think about NPM

[arunoda]

Now we’ve a preview version of Meteor 1.3. See: Meteor 1.3 *early beta* now available

Apart from the module support, it has native NPM support. That means, you could import NPM packages inside the node_modules directory. So, sooner or later we may need to publish our packages to NPM rather to Atmosphere.

I just started to considering porting some of our Meteor packages to NPM and I found it so harder to find a good way to write ES2015 inside as a NPM package.

It took me a while to setup a good environment with liniting, testing and proper transpilation. I made it as a base repo so everyone can use and we’ll support it.

Check it here: Easiest Way to Write a NPM Module in ES2015

[dcworldwide]

Really excited that 1.3 should mean an end to atmosphere wrappers for npm packages

[juliancwirko]

I’m also tired of creating wrappers for Npm packages and the npm-base is really helpful. Thanks for that. Just started to rewrite one of my Meteor packages in React and it will be only Npm package.

[tjmonsi]

@arunoda just an off-topic question but… can we now use GraphQL in Meteor with the ability to just add the npm package?

[arunoda]

NPM should not be the problem for that. We had ways to use NPM.
What we need some client side tooling. I’m working on it.

[bysabi]

@arunoda I was trying to move my packages to npm aproach and migrate views from Blaze to React but some templates will stay on Blaze. I’m unable to figure out how export/import Blaze from npm. Do you know it?
Any repo example?

[arunoda]

I don’t think that’s possible right now.
Only possible reason to write NPM modules right now is for re-usable React components and some other non-meteor libraries.

[SkinnyGeek1010]

Could the NPM module assume that Meteor and Template for example is globally available and the user would have to make sure that Meteor was ready before importing?

[arunoda]

I didn’t try but that’s totally possible.

[trusktr]

Yep, that’s what I thought too. The maker of the NPM package would assume it runs in Meteor with globals.

Alternatively (@benjamn Since you’re working on modules) there could be a meteor meta-package to import symbols from:

import Meteor from 'meteor'
import {Tracker, Session /* , etc */ } from 'meteor'

or

let Meteor = require('meteor')
let { Tracker, Session /* , etc */ } = require('meteor')

[bysabi]

I create two 1.3 issue related to NPM behaviour.

What you think?

Issue: [1.3][proposal] import from NPM on local package

Issue: [1.3] support for local NPM packages

[dinos]

Just want to chip in here regarding the boilerplate and what to do if you prefer - like we do - to create meteor agnostic npm packages now. Since we’re on npm, we can not only provide ES2015.

@benjamn made some crucial points (see below) about how npm packages should look like to transition to true ES2015 import / export statements. Since npm is currently split between ES5 and ES6 he basically advocates the jsnext property inside a package.json to provide both the ES2015 and transpiled ES5 js entry points: Checkout the jsnext-skeleton boilerplate

He gave a talk in November (video below) about this issue in which he pleas to publish both source files and (if you care about npm) transpiled js routed via the ‘jsnext’ property (slide 71+)

I personally like the skeleton very very much - untying everything in a npm package from meteor. @arunoda what do you think? Maybe you can include this alternative in your medium post / faq section?

Is Meteor Dying? State of the Meteor Ecosystem

Another serious problem with Webpack is that it assumes we're going to be using CommonJS forever. Two of Webpack's shiniest features, code splitting (require.ensure) and hot module reloading (module.hot) depend on CommonJS-isms (require and module) that will and should cease to exist in a fully ES2015 world of import and export, and Webpack has no plan to adapt those techniques to work with a purely native module system. The more popular Webpack gets, the more it contributes to the entrenchmen…

[trusktr]

He gave a talk in November (video below) about this issue in which he pleas to publish both source files and (if you care about npm) transpiled js routed via the ‘jsnext’ property (slide 71+)

This is good idea in general that I’ve been using in libraries I contribute to or write: If you’d like the most people possible to use your library, include all forms of your source (original, compiled, global UMD) in your package since each form is still just a script, with instructions on how to use each. I usually put original files in a src folder, compile everything into lib or just into the root of the project, and also place a global version at the root.

[tgoldenberg]

Wait, so how do we bring in old templates into our new import / export React code? I’m used to BlazeToReact('template') but that doesn’t seem to work. Any suggestions?

[trusktr]

That should still work. Template always load before JS, so I’m not sure what that’s not working. Make sure the package that provides BlazeToReact loads before your main.js entry point.