Harold Treen

Next thing causing long load times - `lodash`. `editorInterface` is requiring all of `lodash/fp` so that it can use `_.flow`. `updateStatusTileScope` and `linterInterface` are requiring all of `editorInterface` in order...

Could do. I've actually opened a PR that solves the `lodash` problem with lazy loading and importing `flow` directly. https://github.com/prettier/prettier-atom/pull/335 `lodash` doesn't appear to be a part of activation anymore,...

Been digging around a tiny bit more. Some thoughts: - `import-lazy` is nicer syntactically then having many lazy callbacks, but adding it everywhere doesn't necessarily uncover big savings. - `setTimeout`...

Looks like other packages use `requestIdleCallback` (which is slightly better than using `setTimeout`). It looks like that can also be used for installing dependencies. I bet that would shave off...

I've been trying to blog about these random open source patches. Show libraries I like. Show how welcoming they are to contributions. Show open source isn't scary. So my last...

Seeing a regression on this one - `async` / `await` being used requires a polyfill that adds ~65ms to the startup profile: 

While looking at the `.bablerc` env I noticed that electron supports a lot of the features that were triggering polyfill issues in the past (eg. `...`). So hopefully fixing the...

Looks like this has become a thing again 😅 

Looking at the diff I suspect... - `require('lodash/fp')` is back in the [critical path](https://github.com/prettier/prettier-atom/compare/eed59fa86cfe5db82625f6fb9a2a339baa3e18a8...master#diff-9076a080297e6a840f8a23573a354ce5R2) of loading (In this PR it reduced the activation time by 120ms - https://github.com/prettier/prettier-atom/pull/335) - There's...

The chrome debugging docs have been written: https://github.com/haroldtreen/epub-press-clients/blob/master/packages/epub-press-chrome/DEBUGGING.md