Meteor 1.3 / Modules support: Is there a way to access ecmascript exports in the browser console / meteor shell?

help
1

Hi, while developing it’s always nice to be able to quickly run a piece of code on the browser or Server Console.

Now that I’ve started wrapping my exports in, well, exports instead of a global “Namespace” (AKA Object) of my own choosing I suddenly don’t know how to access my own code anymore from the console / shell.

Is there a way to access my module exports from the console with eg. the Google Chrome browser console?

Or do I need to assign my objects to some global or another just to have access to them?

KThx for any help! :slight_smile:

2 Likes
2

One way you can do this is by using require. For example:

Chrome console:

Meteor shell:

730×383 11.7 KB

2 Likes
3

Another way, if you want a quick solution, in whatever your entry point is:

if (Meteor.isDevelopment) {
  Collections = require('./lib/collections').default
}

Then this will put it on the global scope in development

2 Likes
4

This is what I do. My Collections, Services and Utils are all available globally in development only.

1 Like
5

Thanks everybody! Great solutions which take away the hassle of having to assign everything to my own namespace manually! Very much appreciated, thank you once more.

6

I’m trying to do something similar from the official meteor 1.3 todos’ tutorial. I know 1.3 got rid of global variables and recommends we use modules. All I want to do is manipulate the collection and test out commands on the collection from the javascript console as per 1.2 and earlier, at least whilst in development mode.

Yet it won’t work:

For the record, api/tasks.js is just:

import { Mongo } from ‘meteor/mongo’;
export const Tasks = new Mongo.Collection(‘tasks’);

Am I missing something really basic here? Sorry if it sounds silly. I’m not sure how to get access anymore.

1 Like
7

You loaded it correctly but the collection is nested inside the object that is returned.

So something like this will work as expected:

var Tasks = require("./imports/api/tasks.js").Tasks;
2 Likes
8

You defined Tasks as a named export so, the default export would indeed be undefined

When you typed ‘n’ in the console the first time it showed the Tasks: ns.Collection property on the object (showing that it’s an instance of ns.Collection), so it would be used as n.Tasks.find().fetch()

1 Like
9

Thanks @reoh! That worked. But only against require(’.imports/api/tasks.js’); Earlier in this thread it mentioned appending .default to the end of the require statement, which then breaks your solution. Is there a reference in the docs you can point to on this?

@ramijarrar sorry that didn’t work, but thank you.

10

See: https://docs.meteor.com/#/full/modules
Another great resource: http://exploringjs.com/es6/ch_modules.html

In your case, to use the require('tasks.js').default you would have this code:

export default Tasks = new Mongo.Collection('tasts');

Also,

var Tasks = require("./imports/api/tasks.js").Tasks;

should work for the named export

It’s recommended to use default exports when possible

2 Likes
11

@reoh Awesome. Works. Fwiw, if you use export default, instead of export const Tasks in tasks.js, it fails, but otherwise works. Thanks for the resources!

12

There was a typo in the collection name but we are both suggesting the same thing :slight_smile:

Anyways, glad you managed to figure it out.

1 Like