Ease of integration (build config)

[siddharthkp]

I touched upon this in: #3 and #349

So here's the thing, almost all React applications will depend on babel-preset-react, either by adding because of create-react-app or by adding it in their babel config (manage does this)

We use 2 features that are in an awkward spot.

• transform-object-rest-spread
• transform-class-properties

You can use them in your application (like manage), but a dependency of yours cannot use it (like cosmos). There's a feature request open in create-react-app.

For now, we have 2 options:

• Ask products to add another line into their babel config:

  {
    "presets": [
      "react",
  +  "auth0-cosmos/babel",
      ["env", { "targets": { "browsers": ["last 2 versions"] } }]
    ]
  }

• Not use these features

---

What difference does it make?

• Even though it's one tiny line, I would like cosmos to be a drop in dependency with no extra configuration needed.

• Folks using create-react-app will either have to eject or use something like react-app-rewired in order to use cosmos

• There's added benefit we can get from a babel-plugin like enabling better debugging for styled-components: Better debugging of classnames #166, so it's not a bad idea to introduce it from the start (or maybe this should be an opt-in feature?)

[nkohari]

Maybe a silly question: is there a reason we don't just ship the transpiled JavaScript? It'd be nice to be able to use language features freely inside of Cosmos without worrying about what version of ES (or Babel) consumers are using.

[siddharthkp]

is there a reason we don't just ship the transpiled JavaScript?

My reason is not knowing the right transpile target: ES6 + React presets? ES6? ES5?

Covered it in #3 (short version):

4. What code do we ship? (packaging)

By shipping the source we give the application developers more power in terms of transpilation and tree-shaking.

Example: If the application only supports only the last 2 versions of browsers (manage does that), they have the opportunity to have smaller bundles by shipping ES6 code. If we ship an ES5 bundle, they are taking a performance hit.

On a similar note, if the application uses styled-components already, we don't want to package it with cosmos as well and end up with 2 versions of it.