Expose mdc-ripple's util.js for ES5

[Hardtack]

I'm implementing custom MDCRippleFoundation adapter.
As you mentioned in document, supportsCssVariables function in util.js would be useful to implement browserSupportsCssVars() => boolean.
But, @material/ripple/dist/mdc.ripple does not exposes the utils module. So I cannot use the module without transpiler configured for MDC.

/*
 * In `some_library/src/foo.js`
 * Will be transpiled to ES5 code in `some_library/lib/foo.js`
 */
import {supportsCssVariables} from '@material/ripple/util';

...

If i use transpiler to use that module, users of some_library also have to use same transpiler. But It does not seem to be good constraints.

/* In application that does not use any transpiler  */

// Raises syntax error when importing `@material/ripple/util`
var RippleWrapper = require('some_library/lib/foo.js'); 

[codesuki]

I also had that problem.

Anyhow for now you can circumvent it by doing the following:

rippleFoundation = new MDCRippleFoundation(Object.assign(MDCRipple.createAdapter(this), {
// your funcs
}

This will give you a default foundation that already uses supportsCssVariables so you don't have to implement it yourself.

[traviskaufman]

Hey @Hardtack,

We try to keep exposition of util modules in our ES5 sources to a minimum, and instead encourage people who want to make use of those util functions to use a transpiler to transpile our ES2015 sources. And added benefit of transpiling our modules is that you also don't get all of the webpack/UMD-specific artifacts that are present within our ES5 sources. Is there something within your build system that makes it difficult to include MDC-Web sources as a transpilation target?

If i use transpiler to use that module, users of some_library also have to use same transpiler. But It does not seem to be good constraints.

I'm not sure I understand why users would also have to use a transpiler. If you're transpiling our source files as part of transpiling some_library, wouldn't that mean that all an end user would have to do is pull in the entire transpiled bundle?

As @codesuki we made MDCRipple.createAdapter() for this purpose of smoothing over some of the more rough edges in the ripple's adapter API. If this solve is inadequate for you, let us know and if there is a strong enough argument for exposing util as part of an export on the main ripple component I'm sure we'd consider it.

[Hardtack]

@traviskaufman

When I transpile my code to ES5 without webpack just with babel, it does not copy required module into output file. Like this:

/* `some_library/index.js` */
import util from '@material/ripple/src/util';

...

⬇

/* `some_library/index.js` */
'use strict';

Object.defineProperty(exports, "__esModule", {
  value: true
});

var util = require('@material/ripple/src/util');

...

And when user of some_library import this, without any transpiler, It will occur errors at

var util = require('@material/ripple/src/util');

It means, imported module should always compatible with ES5 even if we are using transpilers.

I can't understand why third party library depended on MDC-Web developers should have to bundle MDC-Web's code into their packages.
It ties third party library's published code to specific version of MDC-Web which is downloaded in node_modules directory in package publisher's local environment.

Is there any plan to provide util modules like CommonJS way?

[traviskaufman]

@Hardtack fair point. I can see the value in exposing the ripple's util module via index.js. However, as a general rule we'll probably only expose util-like modules on a case-by-case basis.

We don't want to add too much to a public API right off the bat, only to change/remove something thus causing a breaking change.

[traviskaufman]

Work which needs to be done:

• Export util from index.js
• Document util within the README, saying it's convenience methods for implementing ripple adapters