Currently the compiler has built-in options and doesn’t accept additional ones,

The DukPY based TypeScript compiler also provides a WebAssets (
http://webassets.readthedocs.org/en/latest/ ) filter to automatically
compile TypeScript code in your assets pipeline. You register this filter as
typescript within WebAssets using:

You can pass options to the BabelJS compiler just as keywords on
the call to babel_compile().

The DukPY based BabelJS compiler also provides a WebAssets (
http://webassets.readthedocs.org/en/latest/ ) filter to automatically
compile ES6 code in your assets pipeline. You register this filter as
babeljs within WebAssets using:

Which makes the filter available with the babeljs name.
Only supported filter option is currently BABEL_MODULES_LOADER with value
systemjs or umd to specify that compiled code should use SystemJS
or UMD instead of CommonJS for modules.

The DukPY based JSX compiler also provides a WebAssets (
http://webassets.readthedocs.org/en/latest/ ) filter to automatically
compile JSX+ES6 code in your assets pipeline. You register this filter as
babeljsx within WebAssets using:

Less Transpiling

The DukPY based LESS compiler also provides a WebAssets (
http://webassets.readthedocs.org/en/latest/ ) filter to automatically
compile LESS code in your assets pipeline. You register this filter as
lessc within WebAssets using:

Using a persistent JavaScript Interpreter

The evaljs function creates a new interpreter on each call,
this is usually convenient and avoid errors due to dirt global variables
or unexpected execution status.

In some cases you might want to run code that has a slow bootstrap, so
it’s convenient to reuse the same interpreter between two different calls
so that the bootstrap cost has already been paid during the first execution.

This can be achieved by using the dukpy.JSInterpreter object.

Creating a dukpy.JSInterpreter permits to evaluate code inside that interpreter
and multiple eval calls will share the same interpreter and global status: