-
Notifications
You must be signed in to change notification settings - Fork 71
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
Why are interface declarations removed? #24
Comments
Is this a runtime error, or typescript error? Could you post how you export the interface from |
The thing is that the file isn't generated at all, and it fails when using the library in another project. |
Wait, are you expecting export interface RenderedCell
{
// ...
} Could you give more details on your project structure? (file tree, tsconfig, rollup config, etc) |
yes I'm expecting it to be generated. Here are my configurations : running the build : I didn't put the whole tree because it's a quite big library and it's more noise than signal. But you can already see that many files aren't generated in the dist. rollup.config.ts
tsconfig.json
RenderedCell.ts
File tree
|
Ah, I see. Is the lib opensource by any chance? Try building with those options: typescript({ verbosity: 2, clean: true }), Check if all files you expect are being processed. If declarations suddenly start being generated then there is a cache problem somewhere. If RenderedCell.ts is not mentioned in output (
If the problem is not obvious then, I'll add more logging somewhere. |
I would love to, might be in the future :) Thanks for the tricks, I will try this on monday. |
If you set If all of this applies to you, I see 2 options:
|
Hi, sorry for the long delay, I tried your tips and tricks but I still couldn't get the type definitions for interfaces generated. I changed the configuration to I'm 100% sure this file is needed, as the I will dive in the code to see if there is a particular reason why those files aren't generated. @wessberg Stop generating declarations for my bundle is not an option as this is a library that is part of a bigger project all written in TypeScript, so if it doesn't have typings it doesn't work. |
So, I made some investigation and created a repository that reproduces my case with a minimal set of configuration : https://github.com/onigoetz/typescript-rollup-experiment I also included a webpack configuration to compare how webpack makes it work. My understanding of the problem is that when rollup-plugin-typescript2 requires the compiled version of a file (let's say index.ts) Typescript will return the compiled files and it's imports, but without the interfaces in the imports. That's why rollup never generates them : it's not aware of their existence. To run the repository do an |
If you add: Unfortunately, Rollup doesn't invoke the transform handler of plugins for declaration-only files such as files containing only type declarations. The thing above should work since that forces Rollup to evaluate the file. This issue: rollup/rollup-plugin-typescript#28 explains how and why this issue exists. Theoretically, we could manually resolve all dependencies of your application from the entry point and determine those that only contain type declarations, but there is no way of forcing rollup to invoke the transform hook (beside other obvious downsides such as much added build-step complexity). I'm afraid we can't do much about this without altering rollup itself. The "hack" I described should work for now though. |
Yep, just checked, adding When importing types only, typescript elides import statements from js output and rollup doesn't see those files and thus doesn't send them for transpiling. I'll try to cheat and monitor which files typescript requested from disk vs which files rollup sent for transpiling. Should be possible to force-transpile the difference with definitions only flag. This might result in too many d.ts files in some cases I though (for things rollup has legitimately shaken from the tree for example) |
Thanks for looking into it, I will also check if I can make a contribution for this. |
@onigoetz, ok, try your project with master. Check if right declarations are generated, but also check that no unexpected ones are :) |
Awesome, you litteraly fixed it while I was sleeping :) I tested it and it almost works fine. There is just a small issue, but I think it's something we can't do anything against, the webpack loader does exactly the same and the file list is generated by TypeScript itself. As an example; If I have three files in my repo :
|
Cool, thanks for testing. I'll release it a bit later after another issue is confirmed. Yeah not much we can do when bypassing rollup. You should be able to exclude those files manually in |
Ok, in 0.5.1 now |
work well, just configure {
"compilerOptions": {
"module": "es2015",
"target": "es5",
"declaration":true,
"declarationDir": "lib",
"typeRoots": [
"node_modules/@six006",
"node_modules/@types"
],
"lib": [
"es2015",
"es2017",
"es5"
],
},
"include": [
"src/index.ts",
"src/module/**/*.ts"
],
"exclude": [
"node_modules"
]
}
|
YMMV but I got it to work like this ... before export type MyType = { ... }; after type MyType = { ... };
export { MyType } |
For what it's worth, I just call "scripts": {
"build": "rollup -c",
"postbuild": "tsc --emitDeclarationOnly"
} |
See #211 for the root cause of this. The workarounds here provide a way of getting past this in many situations, but not quite all of them. Resolving #211 (and related type-only issues) should fix this class of bug entirely. |
Hi,
I'm trying to move from webpack to rollup for a library and I have trouble getting declarations to work correctly.
It seems that interfaces declarations aren't exported, this is a problem when I have things like :
I get the error that RenderedCell can't be found.
I worked in webpack, and I can't understand what's the difference in my configuration that broke this. but I seem to understand that it's normal with Rollup.
BTW. I'm using the latest rollup, rollup-plugin-typescript2 and rollup-plugin-uglify I can post my configurations if needed
The text was updated successfully, but these errors were encountered: