How can I use ECMAScript 6 modules for front-end development? - ecmascript-6

I would like to use the ECMAScript 6 module system in a front-end project, so that the interdependencies of the code were more clear than simply loading "all that might be needed" up front, in the HTML.
However, having the following line in the main JavaScript file does not work:
import fuzLogin from 'fuzLogin'
The error in the browser's console is: can't find variable: require
The compiled code (created by Babel) is:
var _fuzLogin = require("fuzLogin");
var _fuzLogin2 = _interopRequireDefault(_fuzLogin);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
Is ECMAScript 6 module system supposed to work, for compiled code, with WebStorm 10?
Should I maybe add some external dependency in my HTML, to provide the missing require?
Are there other ways I could reach a modular front-end orchestration of my JavaScript side?

I think that you're babel configuration is set up to use commonjs that transpiles with require (requirejs)... so, in order to work with that configuration you need to include requirejs: http://requirejs.org/

I found two ways that fulfil what I was looking for, in slightly different ways:
jspm
Rollup
JSPM allows on-the-fly loading of ES2015 modules, so that the transpiling happens in the browser. This is pretty awesome, really, and something I wasn't expecting.
In addition, JSPM also provides traditional build tools for doing the bundling for production.
But I actually chose to go with Rollup.
Rollup gathers all kinds of build systems together, and is based on ES2015 packaging, providing what I was after. Most important for me were the brilliant blog posts by Jason Lengstorf (just 1 and 2 weeks old, btw) that walk one through the whole practical setup.
References:
jspm-trial (GitHub) repo that I did, experimenting these things
Smaller, More Efficient JavaScript Bundling Using Rollup (blog, Aug 2016)

Related

Add custom Jinja2 filters/tests to MkDocs

While writing a Jinja2 template for MkDocs, I need some processing that is not covered by the filters/tests available (specifically, I need date formatting, which is a recurring example for custom filters in Jinja2-related resources across the Web). How can I define my own filters/tests and use them from templates?
To clarify the question, I know how to register new filters/tests in a Jinja2 environment from Python. My issue is that, as a user of MkDocs, I do not configure Jinja2 myself. So what I’m looking for is a way to hook into the setup that MkDocs performs.
I assume it is possible to add filters from a plugin. In fact, I have found one such plugin (undocumented and apparently not under active development, unfortunately). However, I hope that there is a simpler, local solution; one that would not involve implementing a plugin, packaging it as a Python package and publishing it on PyPi.
A possible solution is to use mkdocs-simple-hooks that allows to implement the hooks without needing to create a plugin. For example in your case:
plugins:
- mkdocs-simple-hooks:
hooks:
on_env: "docs.hooks:on_env"
docs/hooks.py
def on_env(env, config, files, **kwargs):
env.filters['my_filter'] = my_filter
env.tests['my_test'] = my_test
return env

Load ordinary JavaScripts in Polymer 3 elements or lit-elements

I am in the middle of converting a Polymer 2 app to Polymer 3. Modulizer did not work for me so I converted it manually. Thanks to the great upgrade guide it has been mostly straight forward so far.
One task is left though:
in my Polymer 2 app I had a special html import (d3-import.html) that brought in the d3.js lib version 3 which comes as a plain JavaScript file (no ES6 module!). This import was dynamically loaded in only two out of overall 20 pages because the other 18 pages did not need it.
In Polymer 3 I can not import it as an ES6 module because it is not a module. Loading it in my main start.html would mean it gets loaded even if the user only uses the other 18 pages that don't need it.
I tried writing script-tags in my web component templates but that doesn't seem to work. Unfortunately I don't see any error in the browser tools. The template simply stops to load at the line of the script-tags.
Any idea how to do this?
Additional question:
since I start using lit-element in the same application. How to solve the same problem with lit-element?
Edit: note that I currently don't use any build steps/tools except for polymer-build to replace the module paths with actual file paths.
Note that this challenge has nothing to do with Polymer or LitElement, this is only an issue with how to load non-module resources from a module.
The most straightforward way that I know of is to use a bundler like Rollup that can support CommonJS or UMD. Rollup has the commonjs plugin for this: https://github.com/rollup/plugins/tree/master/packages/commonjs
The other option is to upgrade to D3 5.x, which appears to be published as standard modules itself. Given the number of files involved, you'll still likely want a bundler to reduce network roundtrips.

How do I check what ES version will be required by a browser?

I have a JS application that is bundled using webpack. It is mostly VueJs, with some jQuery and raw JS. It calls in a number of libraries and uses some ES6 features.
I think webpack is transpiling down to ES5, but I am not 100% sure. I would like to be able to check the output JS, to find out if it is definitely ES5 or lower. How can I do that?
I tried this node module, https://www.npmjs.com/package/es-check, but could not get any sense out of it. It keeps saying that it can't find any files to check.
A simple solution could be to use grep or similar on the bundle and search for any of these:
cat bundle.js | grep =\>
arrow function =\>
declarations let\ const\

Compile file with two separate libraries in Cython

I wrote a library in Cython that has two different "modes":
If rendering, I compile using GLFW.
If not rendering, I compile using EGL, which is faster, but I have not figured out how to render with it.
What is the recommended way to handle this situation?
Right now, I have the following directory structure:
mujoco
├── __init__.py
├── simEgl.pyx
├── simGlfw.pyx
├── sim.pxd
└── sim.pyx
simEgl.pyx contains EGL code and simGlfw.pyx contains GLFW code. setup.py uses an environment variable to choose one or the other for the build.
This works ok, except that I need to recompile the code every time I want to switch between modes. There must be a better way.
Update
I agree that the best approach is to simultaneously compile two different libraries and use a toggle to choose which one to import. I already do have a base class in sim.pyx with shared functionality. However this base class must itself be compiled with the separate libraries. Specifically, sim.pyx depends on libmujoco.so which depends on either GLFW or EGL.
Here is my exhaustive search of possible approaches:
If I do not compile an extension for sim.pyx, I get ImportError: No module named 'mujoco.sim'
If I compile an extension for sim.pyx without including graphics libraries in the extension, I get ImportError: /home/ethanbro/.mujoco/mjpro150/bin/libmujoco150.so: undefined symbol: __glewBlitFramebuffer
If I compile an extension for sim.pyx and choose one set of graphics libraries (GLFW), then when I try to use the other set of graphics libraries (EGL) this does not work either unsurprisingly:
ERROR: GLEW initalization error: Missing GL version
If I compile two different versions of the sim.pyx library, one with one set of libraries, one with the other, I get: TypeError: unorderable types: dict() < dict() which is not a very helpful error message, but appears to result from trying to share a source file between two different extensions.
Something like option 4 should be possible. In fact, if I were working in raw C, I would simply build two shared objects side by side using the different libraries. Any advice on how to get around this Cython limitation would be very welcome.
(This answer is just a summary of the comments with a bit more explanation.)
My initial suggestion was to create two extension modules defining a common interface. That way you pick which to import in Python but be able to use them in the same way once imported:
if rendering:
import simGlfw as s
else:
import simEgl as s
s.do_something() # doesn't matter which you imported
It appears from the comments that the two modules also share a large chunk of their code and its really just the library that they're linked with that defines how they behave. Trying to re-use the same sources with
Extension(name='sim1', sources=["sim.pyx",...)
Extension(name='sim2', sources=["sim.pyx",...)
fails. This is because Cython assumes that the module name will be the same as the filename, and so creates a function PyInit_sim (on Python 3 - Python 2 is named slightly differently but the idea is the same). However, when you import sim1.so it looks for the function PyInit_sim1, fails to find it, and gives an error.
An easy way round it is to put the common code in "sim.pxi" and use Cython's largely obsolete include mechanism to textually include that code in sim1.pyx and sim2.pyx
include "sim.pxi"
Although include is generally no longer recommended and cimport is preferred since it provides more "Python-like" behaviour, include is a simple solution to this particular problem.

Django: auto minifying css/js files before release

I have following case: I want to use uncompressed js/css files during development (to debug js for example) but on production I want to switch automatically to minified versions of that files.
some simple solution is to put in your template:
<script src="some_js.{% if not debug %}min.{% endif %}js"....
but this require manully providing that such file exist and to do minifaction manullay after original file change.
How do you accomplish this in your projects? Is there any tool for this?
Did you try django-compress ?
See http://djangopackages.com/grids/g/asset-managers/ for a fairly complete list of available asset managers for Django...
If you already are using django-compress, you should have a look at upgrading to django-pipeline, which is a well maintained fork, with a lot of new features. I encourage everyone to who is using django-compress to switch to django-pipeline instead: * django-pipeline documentation
Django-compress is no longer being maintained. Try https://github.com/cyberdelia/django-pipeline instead.
I've been using webassets and so far I'm very satisfied. What I really like about it, is that you're still able to define your CSS and JS files inside of your templates, instead of in the project configuration.
Documentation can be found at: http://elsdoerfer.name/docs/webassets/
As of the end of 2016, these answers are mostly outdated.
Check here for a few options:
https://gitlab.com/rosarior/awesome-django#asset-management
At the moment, django-compressor is a good choice, but there are alternatives depending on what you want to do. I believe webpack is becoming popular these days as well.
I wrote this Makefile to minify and concatenate my JS and CSS files. It depends on the YUI Compressor JAR.
After updating a file, you still have to run make though. Nevertheless, you can make it run when the server starts and/or reloads, or setup a commit-hook on your SCM.
Of course you still need the {% if not debug %}, but it's a small price to pay IMO.
Showing the simple usage:
$ make
[css] static/css/first.css
[css] static/css/second.css
[css] static/css/third.css
[css] static/css/and_so_on.css
[tag] #import url("static/css/all.css");
[js] static/js/first.js
[js] static/js/second.js
[js] static/js/third.js
[js] static/js/and_so_on.js
[tag] <script type="text/javascript" src="static/js/all.js"></script>
Done.
Just released an open-source project that watches directories for changes and auto-minifies JS, auto-compiles SASS/SCSS, runs command line operations, etc.
Check it out at http://devWatchr.com/
It runs using python and pyinotify on your system during development.