Replace babel-polyfill with library-contained alternatives about particle-api-js

[lourd]

Hey @emcniece, thanks for your initial work. One simple fix is to use explicit userland modules instead of relying on polyfills. For example, use object-assign and the object-keys npm packages instead of relying on Object.keys and Object.assign being implemented in the runtime.

I believe those are the only functions that babel-polyfill is actually fulfilling in this package.

[monkbroc]

Version 6.0.1 now uses babel-runtime instead of babel-polyfill. If anybody is still having an issue with the transpiler or sees only one instance of babel-polyfill is allowed please comment and I'll reopen this issue.

[emcniece]

Confirmed that this works within my project - thank you!

[brycekahle]

For instance, polyfilling Promises when Node 4 and 5 have them natively.

A polyfill will not override an existing native implementation. The difference between babel-polyfill and babel-runtime is whether or not the global namespace is modified to support ES2015.

I can see why an app developer wouldn't want extra code that they don't use. I don't like that we get a full polyfill while only using a few of them. I want to try a couple different ways to get only specific ones we use. Would that alleviate your concerns?

[lourd]

Sure. I've seen from a few libraries that want to be explicit specifying individual babel plugins in the .babelrc file instead of using a preset.

[brycekahle]

That works for syntax transforms but not runtime dependencies.

[lourd]

Right. The solutions I can think of are either tree-shaking in the build process with Rollup or Webpack 2, or switch to explicitly using each polyfill you need.

[emcniece]

So I just hit an issue while trying to use particle-api-js in a pre-compiled angular environment:

Uncaught Error: only one instance of babel-polyfill is allowed

I'm including the script directly in HTML because this is a restrictive node/angular plugin-esque system and I can't get NPM modules through to the front end, which is frustrating to say the least. Is this related to this issue?

[emcniece]

@lourd @brycekahle a penny for your thoughts :D

[lourd]

Haha 😉

@brycekahle, any progress made on this? It looks like the methods that may need polyfills are limited to Object.assign and Object.keys.

[brycekahle]

Unfortunately no progress. I'm pretty swamped at the moment so if you have time to put together a PR that polyfills only the necessary features that would be really helpful.

[emcniece]

Cool, thanks @brycekahle!

@lourd - this is a bit beyond my knowledge, but I'll try to help out. Here's a first step - it's not working, tests fail on trying to find babel-runtime. I'll navigate this maze over the next week or two, but some tips would be greatly appreciated ;)

https://github.com/emcniece/particle-api-js/tree/babel-runtime-conversion
https://github.com/spark/particle-api-js/compare/master...emcniece:babel-runtime-conversion?expand=1

[emcniece]

I gave your links a shot tonight, and they don't seem to be compatible as they use require instead of import. I looked around for some other ES6 ObjectAssign polyfills and they all seem to use require, which Babel fails on. (6:1 error 'require' is not defined no-undef)

I must be missing something obvious...

[lourd]

That sounds like a linter error, not an actual program error.

require is built into Node. It's part of what's known as the CommonJS module system. import is part of the ES6 module system, as you mentioned. The Babel configuration for this project transpiles the import statements into require statements. Node does not support ES6 modules natively yet (work is underway, Google '.ejs vs package.json' for some fun reading over the debates happening right now).

So you can use import without a problem, i.e. import assign from 'object-assign'. The linter is setup to enforce using the new syntax.