James Garbutt

The common solution i've always seen is the logical: * Consumed types are dependencies, just like consumed dependencies are * Build-related/tooling types are dev dependencies They are no different from...

I think an important thing to realise here is that the types are paired with the modules they represent. I can see your point of view but a language feature...

i mean this still drills down to the fact that we want the package to be consumable by typescript users. in order to do that, you should (as DT does)...

technically we could still use it but have a different target for those packages (ES5 or some such thing), possibly? TS would transpile down to compatible syntax otherwise don't mind...

true. do both of these packages support async/await? (i.e. is the node version high enough?) webhook and web-api afaik the commit this PR is about contains only those two packages...

rebased and dropped the typescript. build doesn't seem to have started but tests did pass locally

@aoberoi so i've updated to assert for non-assertionerror errors. it still doesn't seem ideal but its simpler than adding complexity or new dependencies to have an async `throws` kinda pattern/assertion....

These are pretty useful. We've been playing around with the types too so thanks for going to the effort of sorting the docs out.

@daKmoR any idea what to do here? i understand downgrading solves the problem, but this isn't obvious from any of your docs, examples, etc. currently someone (like i did) might...

@lucaelin maybe several issues at once. the error about exports is unlikely to be from the helpers module. https://github.com/rollup/plugins/blob/4e85ed78cd2e941107fdf0e8e118e7bee550109d/packages/commonjs/src/index.js#L241-L243 this doesn't load because the node-resolve module executes first in WTR/dev-server...