Rmwc: Published version should either polyfill ES6 methods (Array.fill... etc), or document necessary polyfills.

[jamesmfriedman]

This will address issues with Array.from, String.startsWith, and Set

[SleeplessByte]

You could consider having a dist/ es6 version and a unminified and minified rmwc.dist.js es5 version. Maybe this is what you're intending to do, but naturally npm allows for this using the main: package.json key.

[jamesmfriedman]

It's already published to (mostly) es5. It's really just a few prototype methods that babel has documented that it doesn't transpile. Other than that, I'm all about supporting the lowest common denominator.

[SleeplessByte]

But when someone is consuming this library, wouldn't you want them to be able to use THEIR target, not the "lowest common denominator"? Why would a library transpile for es5 (as only option) if its consumers are targeting next?

IMO since it's npm standard that the library is there in es5 I do agree that you should do the transpiling, but as a consumer I also want to consume the library as es6 and apply my own rules, if any.

It's more and more common that you would do both, so the consumer can "choose", which I right now only can do by targeting a git sha.

[j-o-d-o]

I don't really get in which use case you would want to "consume the library as es6 and apply my own rules"?

[jamesmfriedman]

@SleeplessByte uses ParcelJS which is a new build system...

Most build systems don't apply babel to your node_modules folder because it slows down your build time considerably. The bug that we ran into with Parcel was exactly that, it was running babel on everything.

It is NPM standard to publish transpiled code, this isnt an opinion of mine. If you don't believe me, go look at your node_modules folder at the code you're importing. This ensures that it works for everyone and that they don't have to reconfigure their build anytime something changes in javascript, which is every few minutes.

[SleeplessByte]

@jamesmfriedman @j-o-d-o actually this is the same with webpack, and you can even apply this when using rollup. ParcelJS is a whole different story. It should NOT have been running your babel options. It should have been running my babel on your code, but they are still establishing how they want to deal with this.

Surely I am not advocating doing one over the other, I am saying just set up your publish script to do all of them. I agree that there are definitely use cases not wanting to rebuild npm modules, but for most build systems (like parceljs, among others) a build cache complete removes the "slowness" limitation.

The use case is that I don't need my loops transpiled (read: not use native functions / become less flat), or other newer functions transpiled. Personally I don't have any issues. I grab the source and build it myself 👍 I was simply suggesting to not just build a single version whilst NPM is still es5 only.

Sidenote: As far as I can tell NPM requires you to have an index built with es5 exports, not transpiled code, which is... peculiar.

Starting March 2017 angular did this too:
https://github.com/angular/core-builds/blob/dc0c8d828a8bae6591d2b9c77974271481af818c/package.json#L7
https://blog.angularjs.org/2017/03/angular-400-now-available.html

[SleeplessByte]

A lot of package I personally use don't have transpiled code; I know that it is common / used to be common to consume transpiled packages, but NPM does not (!) enforce it to be transpiled. Just to be es5 modules. (module.exports over export x).

lodash-es build is exactly this: untranspiled es6 modules:
https://github.com/lodash/lodash/tree/4.17.4-es
https://github.com/lodash/lodash/issues/861

Currently React-Native packages are always (!) untranspiled, and they are also still establishing how they want to move forward
https://github.com/facebook/react-native/issues/10966

[jamesmfriedman]

If you want to tackle having an es6 version and put in a PR that would be a great addition.

Another option is to simply publish the src directory in additional to the transpiled modules.

// Transpiled
import { Button } from 'rmwc/Button';

// Original src
import { Button } from 'rmwc/src/Button';

The only minor down side is slightly longer install times since it's double the code.

[SleeplessByte]

@jamesmfriedman the later would be a great start. And sure -- when I get to it I will. Currently just using your git version + custom typescript definitions (the ones by that other guy were not designed the way I like them) and works like a charm.

I generally copy my src to /dist/es6 or whatever to do just that: enable es6 output.

[jamesmfriedman]

Checkout the typescript issue #40 . I had the idea of automatically generating Typescript definitions from the generated doc JSON file. Could be interesting.

[SleeplessByte]

Yep, that's how I got to https://github.com/ncknt/rmwc-typed. Generating ts definitions would be amazing, albeit a tad difficult, as your library introduces only a few new types, and they are pretty sound, but because the original base code allows you to plug _any_ tag, type expansion is meh.

Example:

<SomeComponent tag="span" />

Now your flow definitions just ignore this and assign the typescript equivalent of any, but realistically the type should be something like:

type SomeComponent = React.ComponentType<
  SomeComponentProps & 
  React.DetailedHTMLProps<
    React.HTMLAttributes<HTMLSpanElement>, 
    HTMLSpanElement
  >
>

Still unsure if that's 100% coverable but alas; I think having anything in place that's at least partially type-safe or at least for the types you have right now would be great.

https://github.com/bcherny/flow-to-typescript could be interesting. It's a compiler that could run, but for that the flow types need to be better. https://github.com/niieani/typescript-vs-flowtype some interesting differences.

[jamesmfriedman]

Yeah, theres a type for those though. All the types are an intersection with SimpleTagPropsT https://github.com/jamesmfriedman/rmwc/blob/master/src/Base/simpleTag.js#L15

I would just have to go through the codebase and verify that. React-docgen however can't see types that are imported from different files, it just runs statically on the individual components.

[SleeplessByte]

React.ComponentType<any> just loses a lot of information, as does React.Ref<*>;

I think the new title is what I was getting at 👍 .

[jamesmfriedman]

I know this is a long running issue, but switching to typescript in 5.x.x and targeting es5 with helpers should fix this.

[jamesmfriedman]

Fixed with the release of V5