Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@kablamo/kerosense is currently not tree-shakeable #13

nhardy opened this Issue Mar 3, 2019 · 1 comment


None yet
2 participants
Copy link

nhardy commented Mar 3, 2019

In packages/kerosense/src/index.ts, we currently do

import * as arrayUtils from './array';
import * as stringUtils from './string';

export default {

A single default export here is not tree-shakeable, because it is not statically analysable. We should instead export each method individually. To avoid repetitiveness, we could use a similar build system to lodash where the JSDoc of each method is used to automatically generate all the import/export statements in the output and group methods into categories (array, string, etc.).

We also currently just produce CommonJS output which cannot be tree-shaken either. The solution to this would be to produce multiple output files, with the "main" field in package.json pointing to the CommonJS build and the "module" field used by bundling tools pointing to an ES modules build.

We also have a dependency on lodash where we are not currently using cherry-picked method imports (like import identity from "lodash/identity";). I would suggest that either we use cherry-picked imports ourselves, or instead build with @babel/preset-typescript so that we may use babel-plugin-lodash which will do this for us.

@nhardy nhardy added the enhancement label Mar 3, 2019


This comment has been minimized.

Copy link

ojkelly commented Mar 3, 2019

Most of what’s mentioned here is what we want. We want tree-shaking, and the widest module support we can.

I like the jsdoc idea of using that to generate a final file of imports, there may be prior art in the lodash repo we can look at.

We don’t want to be reinventing the wheel, but at the same time we currently have no build dependency on babel, so if we can avoid it — great.

We probably need to get some jsdoc written for the few funcs, before we can get a generated index file.

Also, did you get a chance to see if the ui and feature-flag module need similar work?

@nhardy did you wanna have a crack at a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.