feat: ship TypeScript declaration files - #1837

Thanks, this looks like a useful addition! Note however that the Travis-CI failed dramatically. Since appveyor succeeded, I assume this is an OS specific issue we should figure out.

@lukastaegert all green, issue was some import paths has wrong casing.

Awesome cheers 😁

As a TypeScript developer: thank you! 😄

Note that DefinitelyTyped has a manually authored type definition published as @types/rollup. When the next version of Rollup is released, this type package should be removed in favor for Rollup's own types.

This PR seems to be outputting a full individual file compile of Rollup into the dist folder, along with typings for each of the unbuilt files.

Surely we should just be publishing one top-level rollup.d.ts here for the outward API?

I'm not sure I follow the use case for having separate typings per development module too, will TypeScript really be able to match up the types from these individual files to the dist/rollup.js file?

It seems the typings run through "dist/typings/src/node-entry" as the main file in Node and these are working ok here.

The only issue is that it doesn't support the import rollup from 'rollup' default form and requires users to write import * as rollup from 'rollup' it would be nice if we could get this fixed too.

Well at the moment, rollup doesn't export a default, this has this has nothing to do with typings per see.

Regarding the flatting of .d.ts files this is not yet possible with TypeScript or at least this doesn't come out of the box.

Regarding different types, Typescript doesn't care about environments nor the JS version, there is a single file per module which should contain all types. That's why I choose node-entry as it contains the complete set of types

Indeed, TypeScript doesn't have a way to output a single declaration file yet, see microsoft/TypeScript#4433.

There are tools that try to do this (such as dts-bundle and dts-generator), but they come with their own limitations. Basically, these tools just concatenate the individual .d.ts files into one file, and fix some naming conflicts along the way. They don't "tree shake" the type definitions, so you still end up with one big file with lots of (internal) modules.

My other worry here is that for example the InputOptions in the API here are just a generic configuration object, so a lot of the type benefits aren't actually there.

It could be worth considering manually maintaining the outward .d.ts API file, especially since the Rollup API is so encapsulated, almost all of the types here are internal.

Re ‘InputOptions’ it doesn look like a configuration object and is correctly defined with the proper types. In general i shouldn’t be able to assign an invalid value to the InputOptions.

InputOptions is actual one of those critical types to have.

The main point of TypeScript or one of the them is to have as strongly typed as possible even for the consumers, and in reality to use the API it can become so easy that in some cases you don’t even need to check the documentation as it will be self explanatory by the types themselves.

@alan-agius4 I'm referring to the generic options we take in https://github.com/rollup/rollup/blob/master/src/rollup/index.ts#L208.

I didn't know it was possible to mark types as "internal" in TypeScript... how would we go about doing this?

A dictionary seems to contain uniform information which is not the case here?

Anyway the reason we are using a generic object is because

• we do not want to litter the configuration object type with deprecated options
• we want to check for unexpected keys
• I was not considering others using this type 😜

I think we should actually handle this differently in the future:

• Use a type that only contains valid, non-deprecated options in our signature
• Cast this to a generic object when checking for deprecations and unexpected keys

Anyway, I think there is no harm in keeping this as it is for now (though merging might have been a little premature...) and do incremental improvements. But we should not remove the DefinitelyTyped definitions just yet.