Some old Javascript libraries directly attach an object to the global scope (no AMD, no UMD, no commonJS).
Is there a nice way to "include" a global module in ECMAScript 6 code?
I'm just aware of the following line:
import './globallib.js';
And then access the global variable directly.
Example: to load QUnit test function:
import 'qunit';
test('my test', function () {
ok(true, 'QUnit loaded');
});
Is this the right way?
PS. I encountered this problem while working with QUnit 1.8 in a project that compiles to ES 5 using Babel and Browserify. In QUnit 2 they're gonna avoid globals. But I have this question in general.
As far the QUnit exports its methods into window (according source code), you right, import expression is enough.
But anyway, you can't use raw imports in browsers, so you have to use some preprocessing. Webpack and browserify will work for you, but it would not be so for another build systems.
Related
Previously I've been using following in my JS entry points:
require('coffeescript/register');
module.exports = require('./entry.coffee');
What is the corresponding ES6 syntax of this?
Following does not seem to register anyhing.
import 'coffeescript/register';
export * from 'entry.coffee';
Error is:
Cannot find module 'entry.coffee'
Tested on Coffeescript 2.0 beta2.
Update:
Changing path to relative:
import 'coffeescript/register';
export * from './entry.coffee';
finds the entry.coffee, but treats it as JS. Hence, Coffeescript is not handled by transpiler.
You don't need to use coffeescript/register if you're transpiling the CoffeeScript as part of your bundling process (which you need to, if you're using Rollup) — that's just a way to enable Node to run CoffeeScript files without having to first convert them.
Instead, try adding rollup-plugin-coffee-script to your rollup.config.js file.
I am trying to test lodash, and apparently the following line won't work in the REPL:
import curry from 'lodash/curry';
See, e.g., babel-node es6 "Modules aren't supported in the REPL"
Why does babel-node not support module loading in the REPL?
Is there a way that I can pre-load a module like lodash into babel-node? (e.g. via a command line option or a configuration file)
If not, is there another way of evaluating ES6 with lodash preloaded?
So far, I've tried the online REPL at https://babeljs.io/repl/, and evaluation in the Console in Firefox. None worked.
import surely won't work, because the package should be installed first and bundled in order to be imported, which isn't the duty of Babel REPL.
Lodash is already loaded and used in Babel REPL, it can be used in REPL as _ global:
const { curry } = _;
If the question isn't limited to Lodash, the quickest way to get third-party library in REPL is to load the script manually. And since Babel website has jQuery loaded (as almost any website), the shortest way to do this is jQuery.getScript, in console:
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.js');
After that Lodash _ global becomes available in REPL.
The whole code can be wrapped with callback to skip console part:
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.js', () => {
console.log(_.VERSION);
});
babel-node REPL doesn't support imports, as the links in the original post say. Instead, require should be used, like anywhere else in Node.
var { curry } = require('lodash')
This requires to have lodash installed in node_modules that exists in current working directory.
I am currently learning Meteor and I found out something that intrigued me.
I can load HTML and CSS assets from a JS file using the import statement.
import '../imports/hello/myapp.html';
import '../imports/hello/myapp.css';
import * as myApp from '../imports/hello/myapp.js';
This was a surprise to me so I ran to google but could not find this behavior documented in the specification for ES6 import or in Meteor's Docs.
So my questions are:
Can I rely on this behavior to build my apps?
Will my app will break when Meteor gets around to fix it -- if it's a bug --?
Notes
I am using Meteor v1.3, not sure if this works also with previous versions.
You can download the app to see this behavior from Github
After going through the implementation of the built files for my app
I found out why this works.
HTML
Files are read from the file system and their contents added to the global Template object, e.g.,
== myapp.html ==
<body>
<h1>Welcome to Meteor!</h1>
{{> hello}}
</body>
results in the following JS code:
Template.body.addContent((function () {
var view = this;
return [
HTML.Raw("<h1>Welcome to Meteor!</h1>\n\n "),
Spacebars.include(view.lookupTemplate("hello"))
];
}));
Which is wrapped in a function with the name of the file as it's key:
"myapp.html": function (require, exports, module) {
Template.body.addContent((function () {
var view = this;
return [
HTML.Raw("<h1>Welcome to Meteor!</h1>\n\n "),
Spacebars.include(view.lookupTemplate("hello"))];
}));
Meteor.startup(Template.body.renderToDocument);
Template.__checkName("hello");
Template["hello"] = new Template("Template.hello", (
function () {
var view = this;
return [
HTML.Raw("<button>Click Me</button>\n "),
HTML.P("You've pressed the button ",
Blaze.View("lookup:counter",
function () {
return Spacebars.mustache(view.lookup("counter"));
}), " times.")
];
}));
},
So all of our HTML is now pure JS code which will be included by using require like any other module.
CSS
The files are also read from the file system and their contents are embedded also in JS functions, e.g.
== myapp.css ==
/* CSS declarations go here */
body {
background-color: lightblue;
}
Gets transformed into:
"myapp.css": ["meteor/modules", function (require, exports, module) {
module.exports = require("meteor/modules").addStyles("/* CSS declarations go here */\n\nbody {\n background-color: lightblue;\n}\n");
}]
So all of our CSS is also now a JS module that's again imported later on by using require.
Conclusion
All files are in one way or another converted to JS modules that follow similar rules for inclusion as AMD/CommonJS modules.
They will be included/bundled if another module refers to them. And since all of them are transformed to JS code
there's no magic behind the deceitful syntax:
import '../imports/hello/myapp.html';
import '../imports/hello/myapp.css';
They both are transpiled to their equivalent forms with require once the assets have been transformed to JS modules.
Whereas the approach of placing static assets in the imports directory is not mentioned in the official documentation,
this way of importing static assets works.
This seems to be at the core of how Meteor works so I'd bet this functionality is going to be there for a long while.
I don't know if to call this a feature maybe a more appropriate description is unexpected consequence but that would
only be true from the user's perspective, I assume the people who wrote the code understood this would happen and perhaps even
designed it purposely this way.
One of the features in Meteor 1.3 is lazy-loading where you place your files in the /imports folder and will not be evaluated eagerly.
Quote from Meteor Guide:
To fully use the module system and ensure that our code only runs when
we ask it to, we recommend that all of your application code should be
placed inside the imports/ directory. This means that the Meteor build
system will only bundle and include that file if it is referenced from
another file using an import.
So you can lazy load your css files by importing them from the /imports folder. I would say it's a feature.
ES6 export and import functionally are available in Meteor 1.3. You should not be importing HTML and CSS files if you are using Blaze, the current default templating enginge. The import/export functionality is there, but you may be using the wrong approach for building your views.
I try to repeat example from Mozilla Hacks (Export lists subtitle):
//export.js
export {detectCats, Kittydar};
function detectCats() {}
class Kittydar {}
//import.js
import {detectCats, Kittydar} from "./export.js";
console.log(detectCats); // function detectCats() {}
console.log(Kittydar); // undefined
Oops: Kittydar is undefined (btw., the problem is the same with simple Object).
But if I put export after Kittydar declaration it's ok:
//export.js
class Kittydar {}
export {Kittydar};
//import.js
import {Kittydar} from "./export.js";
console.log(Kittydar); // function Kittydar() {_classCallCheck(this, Kittydar);}
Is this a typo in the article?
I transpile this with babel and bundle with browserify. Then I include output bundle in a usual .html file (with <script> tag).
The standard is hard to follow on this, but the article is correct. This code works in es6draft and in the SpiderMonkey shell: both the function and the class are initialized by the time those console.log calls run.
Here's how it's supposed to work, in minute detail:
The JS engine parses import.js. It sees the import declaration, so then it loads export.js and parses it as well.
Before actually running any of the code, the system creates both module scopes and populates them with all the top-level bindings that are declared in each module. (The spec calls this ModuleDeclarationInstantiation.) A Kittydar binding is created in export.js, but it's uninitialized for now.
In import.js, a Kittydar import binding is created. It's an alias for the Kittydar binding in export.js.
export.js runs. The class is created. Kittydar is initialized.
import.js runs. Both console.log() calls work fine.
Babel's implementation of ES6 modules is nonstandard.
I think it's deliberate. Babel aims to compile ES6 modules into ES5 code that works with an existing module system of your choice: you can have it spit out AMD modules, UMD, CommonJS, etc. So if you ask for AMD output, your code might be ES6 modules, but the ES5 output is an AMD module and it's going to behave like an AMD module.
Babel could probably be more standard-compliant while still integrating nicely with the various module systems, but there are tradeoffs.
I have seen this "destructing" syntax before but haven't ever used it. until now anyways. I want to pull in a react-router repo on github to handle my applications routing (making a single page app). but I noticed that it has this syntax
var { Route, RouteHandler, Link } = Router;
which is just a fancy way of writing
var Route = Router.Route
var RouteHandler = Router.RouteHandler
var Link = Router.Link
so my question is does anyone know if gulp will have any issues compiling this from jsx to javascript?
Do I need to install any additional dependencies for this syntax?
I have done some research but couldn't find anything conclusive. Thanks
The default gulp, yes. JSX syntax needs to be transpiled down to native js. Take a look at gulp-react to see how you can deal with this. Basically , it works in similar concept to other transpiled code (ie. coffeescript). Convert to native before piping along to the next task.
Edit
after seeing you're edit, it looks like you also need to convert the ES6. Take a look at the react browserify, it should help to get you going. Basically the concept is the same, compile jsx/es6 to native js. There's a section specific to the ES6 react components.
2nd Edit
Looks like gulp-react has an option to set to ES6. I think if you add this line, it will work.
.pipe(react({harmony: true}))
//full example
gulp.task('default', function () {
return gulp.src('template.jsx')
.pipe(react({harmony: true))
.pipe(gulp.dest('dist'));
});