blakeembrey / free-style

Make CSS easier and more maintainable by using JavaScript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Providing ES2015 builds

TylorS opened this issue · comments

Hello, first off thank you for the wonderful work here. I've been enjoying this library indirectly through TypeStyle.

Recently I've been trying to update all of my dependencies to provide ES2015 builds and TypeStyle and FreeStyle remains one of the last of them which are commonjs only.

I'd love to create a PR, but didn't want to do so without getting feedback on if it would be accepted. Typically I've created 2 separate tsconfigs, tsconfig-es2015.json and the "standard" tsconfig.json looking something like these

// tsconfig.json
{
  "compilerOptions": {
    ...,
    "module": "commonjs",
    "target": "es5",
    "outDir": "lib/commonjs"
  },
}

// tsconfig-es2015.json
{
  "compilerOptions": {
    ...,
    "module": "es2015",
    "target": "es5",
    "outDir": "lib/es2015"
  },
}

Then in the libraries package.json changing or adding the following fields

{
  "main": "lib/commonjs/index.js",
  "module": "lib/es2015/index.js",
  "jsnext:main": "lib/es2015/index.js",
  "typings": "lib/es2015/index.d.ts" // could just as well be lib/commonjs/index.d.ts
}

Thanks for your time!

Thanks for the issue! I left my comment in #46, but I currently don't see the reason to include these changes. Can you provide more information on why it'd be valuable to add these complications to the build instead of just staying CommonJS? As far as I understand, there's no real chance to save any build size from using ES6 modules. If the changes are accepted, does this create the possibility of fragmentation - e.g. if someone uses deep requires. Also, I'd prefer to build as little as possible - so only one set of .d.ts files. You can use the tsconfig.json extends feature new in TS 2 as well, instead of copying it entirely - never tried it myself, but it might be useful here.

Hello @blakeembrey, per your request on the PR:

I'd like to see this happen, as it allows for ES6-aware bundlers, such as rollup, to perform tree-shaking on unused parts of the library. As you mention most of the library is probably used at all times, but there is definitely a very large overhead of using commonjs in addition to ES2015 modules when bundling. Also, it limits the ability for libraries, such as TypeStyle, to provide ES2015 builds where it is definitely possible to have large unused parts of the library.

I myself have ~95% of my dependencies providing ES2015 builds, and using TypeStyle (I've also opened an issue and PR for ES2015 modules for TypeStyle BTW) in conjunction with this library limits the tooling I'm able to use because of the need to support commonjs. In other words, I've been "forced" to use webpack in order to support commonjs when I much prefer rollup.

The next benefit I see is that it provides a build that is based on an ECMAScript standard.

I'd prefer to build as little as possible

Fair enough, I could update the PR I submitted to not build declaration files and to use the extends feature (I was unaware of this being released) to minimize the amount of duplication.