Combined type definitions (.d.ts) output

[mblandfo]

I'm writing a typescript library for use with other typescript projects. Running ts-loader I got a .d.ts file (in the wrong directory, but that's already a tracked issue).

This .d.ts file contained import statements to import classes from local library files (these would not be shipped) instead of the actual class declarations I needed.

I found a npm plugin that fixes this: https://www.npmjs.com/package/declaration-bundler-webpack-plugin. This plugin has a bug due to a webpack change, but I have pasted a fixed version here: http://pastebin.com/ypqed086

I think that should be the default declarations file behavior.

[JasonKleban]

what is the bug that it fixes? Is it:

            var lines = data.split("\n");
                            ^

TypeError: Cannot read property 'split' of undefined
    at DeclarationBundlerPlugin.generateCombinedDeclaration (...node_modules\decl
aration-bundler-webpack-plugin\plugin.js:44:29)

[mblandfo]

Yes, that is the bug.

It appears the change I made was to change this line:

var data = declarationFile._value;

into this:

var data = declarationFile._value || declarationFile.source();

So presumably webpack changed from using _value to using .source(). I don't think declaration-bundler-plugin has a github or anything (it's just on npm?) I did email the author back in 2016 but he never responded. Can ts-loader be fixed to not need this plugin? It'd be really nice if ts-loader just did this and didn't have to rely on declaration-bundler-plugin at all!

Otherwise I guess someone can make a declaration-bundler-plugin2 package or something.

[johnnyreilly]

@mblandfo - if you'd like to submit a PR I'll take a look

[mblandfo]

@johnnyreilly it looks like this wouldn't be hard to do, like in https://github.com/TypeStrong/ts-loader/blob/master/src/instances.ts at the bottom plugins are getting added, so the fixed version of declaration-bundler-plugin could probably be added there.

I started to write a PR but get errors running tests. I did this:

git clone https://github.com/TypeStrong/ts-loader.git
cd ts-loader
npm install
npm run build
npm run test

and got test failures such as this:

simpleDependency
    1) should have the correct output
    2) should work with transpile


  0 passing (6s)
  2 failing

  1) simpleDependency should have the correct output:

      Uncaught AssertionError: patch0/output.txt is different between actual and expected
      + expected - actual

And then npm printed out a ton of "npm ERR!" lines, which I think were just because there were failing tests.

[mblandfo]

Looking at this more, I think the proposal here is to add a fixed version of DeclarationBundlerPlugin into ts-loader, supporting the options (out, moduleName), and have it only be off by default, since having declarations in separate files is a valid use case. Typescript itself can be run in a mode that outputs a single file and declaration file (the outFile flag), but then, of course, you lose the power of webpack.

So, maybe it looks like this in your webpack config:

{
    test: /\.ts$/,
    loader: 'ts-loader',
    options: {
        declarationBundle: {
            out: 'dist/MyApp.d.ts',
            moduleName: 'MyApp'
        }
    }
}

[johnnyreilly]

I don't really want to create a dependency in ts-loader upon another plugin if possible. If it's a separate plugin then presumably it can be used as such in the webpack.config.js already.

Don't worry about failing tests though. Our test pack is "quirky". Feel free to submit a PR and keep hacking on it until it gets to a good place. Tests will run on Travis and appveyor against each commit

[johnnyreilly]

(and I'm happy to advise!)

[mblandfo]

Oh, I didn't mean create a dependency on that plugin. The issue is that the DeclarationBundlerPlugin is broken due to a webpack api change and no longer maintained. It's also very short, so I was actually planning to just copy the fixed version of the source into ts-loader, with the flag to turn it on. Does that sound ok?

[johnnyreilly]

It's probably fine yes - submit it and I'll take a look.

[JasonKleban]

I'm trying to port Framework7 to typescript and see if the project will accept it. But even with the above patch for DeclarationBundlerPlugin (plugin.js:43:var data = declarationFile._value || declarationFile.source();) to allow it to run through, I'm still getting export default _default; for most of the modules in the combined d.ts. output.

Can that be fixed without altering the structure of the library to not use named exports? Or can it be addressed by this addition to ts-loader?

[mblandfo]

Without the DeclarationBundlerPlugin, ts-loader just outputs a bunch of .d.ts files that refer to each other. Maybe you can just use those? Or, I guess, hand write your own.

The DeclarationBundlerPlugin pretty much just concatenates things, so, named exports are probably not something it could easily handle. Typescript by itself (no webpack) has an option compilerOptions.outFile which if set will combine to a single js and .d.ts, but they require compilerOptions.target to be "AMD" or "System".

Also, for DeclarationBundlerPlugin, I think file export names must match file names.

[JasonKleban]

Yes, this is the situation I'm hoping can be addressed. We'd all certainly need the d.ts files to be generated as part of the automated production pipeline. TypeScript can output single js, d.ts, and sourcemaps in limited configurations, but webpack still needs to be in the mix for other assets and any other post-processing of the generated scripts. Framework7 releases es6 and umd modules as single files. Multiple definition files to accompany them is undesirable. Typescript by itself isn't an good option anyway because webpack or other similar automation is still required for the other assets.

I've already made definitions manually for Framework7 v1 (I'm now looking ahead to v2) so the definitions can be made.

What's the real technical challenge in combining these definitions in webpack & ts-loader alongside the js and sourcemaps? Maybe I could help with it if someone could catch me up. What non-trivial rewriting has to happen? I don't think there's anything unexpressible since it can be done accurately manually.

[mblandfo]

I think you said you got a fixed version of DeclarationBundlerPlugin working on your project, that's probably the best place to start. See if you can modify that to do what you want. If you get something that solves the general cases for ES6 modules or whatever module system, that'd be great! I'm not sure how it would work, like if you can just parse all the import/export/require declarations or what.

It'd be nice to see what the typescript people think microsoft/TypeScript#5090