I realize that I've forgotten to propose a way to define the entrypoint module (as is possible in #4434), and I suppose that warrants discussion, too.

The entrypoint is the location which (in the above example) TS considers the 'top level' for flattening types (in this example, a.ts). Ideally, this is the entrypoint to your library or application. All of the dependent files in a well-formed module-based TS project should usually be accessible from the entrypoint via either imports or triple-slash refs... however In TS's default mode of operation for the --module flag, TS ignores most relationships between included files and compiles them mostly separately, resulting in separate js and dts files for each. Like the proposal in #4434, dts bundling may also make sense to require a --bundleDefinitions [entrypoint] flag, like how bundling module sources could require the --bundle [entrypoint] flag.

On the other hand, rather than add a new compiler flag, we could consider all files specified as 'root' files as entrypoints when compiling with --module and output a definition file for each of them. (Meaning that all other files need to be accessed by those root files and compiled via that relationship.) Conceptually, we could do the same thing with #4434, rather than having the --bundle argument to specify an entrypoint. This does lose the meaning of the --outFile argument, however, since there are suddenly multiple output files (one for each root file) and none of them correlate to the --outFile parameter... So maybe it's best to not try to rely on traversing the dependencies ourselves and require an extra parameter specifying the entrypoint.

@weswigham,

I'm generally in favour of this proposal. I think this feature would help to formalise the idea of a project in Visual Studio (i.e. types defined in namespaces compiled into a a single output file, that can then be referenced by other projects).

One of the problems with a single output file is that it makes life difficult when debugging in the browser. See #192 (comment). Ideally something can be worked out for that as well.

#3159 implements most of this proposal, though it restricts it to ES6 or commonjs modules, uses slightly different terminology for tsc command line flags. and omits the type flattening aspect of this proposal. At the very least, it's probably an excellent starting point for talking about this.

some notes from doing this for Angular:

• should also report a semantic error when a symbol is re-exported to an entry point, but a dependent symbol is not (for example, declared supertypes, parameter types)
• we like to emit a namespace as well as a module, allowing users to use symbols from that global namespace without any import statements (eg. useful for ES5 users in VSCode to get intellisense).
• we might want to be able to use this typings bundle feature without having to use the runtime emit bundling feature from #4434 - for example if there are some errors producing a working emit because of private APIs, it would be nice if we could still use this to produce the public API doc.
• We like to preserve some comments so that tools can show inline doc when showing eg. a completion tooltip. Should probably explicitly mention comment handling in the proposal.

We can't drop our current .d.ts bundler without constructor visibility: #2341

What is the current state of this issue?

It is still in discussion. we have a PR for it, but there are still some open questions.

Can you point to this pull request?

I should clarify, the concatenation is already done in: #5090
The remaining piece is the flatting, here is the PR: #5332

I think that d.ts bundle works very nice, see angular#5796.

Thanks a lot for it.

I jumped to/from many issues regarding this "theme". Is this the right one where discuss?

In my opinion the compiler should be able to produce also separate bundles, like this:

{
    "...": "...",
    "moduleDeclarationOutput": "./modules",
    "modules": {
        "module-a": {
            "from": "./src/module-a/index.ts"
        },
        "module-b": {
            "from": "./src/module-b/index.ts"
        }
    }
}

having then in ./modules/module-a.d.ts the definitions of types exported by ./src/module-a/index.ts and respectively for "module-b".

requesting an update on this please

nothing done since last update. no plans to do anything for TS 2.0 at this point.

@weswigham What do you think would be a best strategy in light of this? Would you recommend building a custom TypeScript with your PR?

I wouldn't recommend it, no. TBH, with recent changes to allow module
augmentation and even proposals for relative paths in module augmentation,
we may have a better way to do this now which can even preserve secondary
entry points.

On Mon, May 16, 2016, 6:24 PM Matthew James Davis notifications@github.com
wrote:

@weswigham https://github.com/weswigham What do you think would be a
best strategy in light of this? Would you recommend building a custom
TypeScript with your PR?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#4433 (comment)

Any other options, then?

Also still looking for support for this.

In addition to outFile, it might be nice to specify outModule if you want the name to be different.

{
  "compilerOptions": {
    "module": "commonjs",
    "declarations": true,
    "out": "./types/lib.js",
    "outModule": "@my-org/example-package"
  }
}

One other alternative to consider would be to declare the module based on the name field in package.json.

I wrote a small script to generate a bundle of your project's declarations:

#!/bin/bash

mkdir -p out

npx tsc ./src/index.ts --declaration --emitDeclarationOnly --out out/index.js --module amd &&

echo "
declare module 'YOUR_PACKAGE_NAME' {
    import main = require('index');
    export = main;
}
" >> out/index.d.ts

It outputs to out, change it as needed, and replace YOUR_PACKAGE_NAME.

What this script does NOT do is to bundle other projects declarations.

Here's my take on it : bundle option with tsc-prog.

Faster than others because it bundles in memory, by intercepting emitted ".d.ts" files during the initial build.

Nevertheless, this is a complicated issue. Corner cases everywhere: name conflict (with global symbols and local ones), namespaces import and re-export, external libraries, json files, import type, etc. Just to name a few I tried to handle properly.

If the intent is to offer a single "d.ts" for a single-script library, then that is a complicated problem. As a thought, a lot of d.ts files are becoming quite large. Maybe it is not the end of the world to keep the d.ts files laid out as per the default. However, maybe instead introduce a "friend" concept for d.ts files.

Idea shopping...

lib/src/internal.ts:
/// <friend modules="~" />; // Says that the only src relative modules can reference this one.


index.ts:
import ... from "./internal"; // Works because ./ matches ~ (src root)
import ... from "../folder/internal"; // Works because ../ matches ~ (src root)

(so far the ts would only perform syntax validation)

app.ts:
import ... from "lib"; // References index.d.ts so good.
import ... from "lib/internal"; // Error: type checker sees that this module is not a friend.

Advantages:

• Promotes size sanity of d.ts files.
• Keeps d.ts files laid out as per the src.
• Completely compatible with current declaration parsing.
• The friend concept can extend across NPM projects potentially enriching options there.
• There is no need to add any new configuration options.
• Multiple "entry points" are valid with this approach without any real additional concepts.

Cons:
Maybe not what people really want.

Hello,

Thanks to everyone for the valuable conversations above. I would like to ask whether any method is known for bundling declaration maps, especially when Microsoft’s API Extractor is in use.

I would like to ask whether any method is known for bundling declaration maps, especially when Microsoft’s API Extractor is in use.

@kripod This forum is for the TypeScript compiler. To ask an API Extractor specific question, please create an issue for its GitHub project: https://github.com/microsoft/rushstack/issues

You will need to provide more detail explaining how the declaration maps would be used. Thanks!

For anyone wondering, which of the mentioned solutions works.
I tried out a few and this one https://github.com/Swatinem/rollup-plugin-dts worked the easiest for me.
Just give it 5 min.
Even if you're not a rollup user, for this single feature it's worth it.
Just use the default config that is provided:

import dts from "rollup-plugin-dts";

const config = [
  // …
  {
    input: "./my-input/index.d.ts",
    output: [{ file: "dist/my-library.d.ts", format: "es" }],
    plugins: [dts()],
  },
];

export default config;

Install the rollup cli:

npm i -g rollup

and execute

rollup -c

We're even using it with the respectExternal option to pull in external types as we're bundling other libraries as well.

For the webpack users, there is also this option via plugin npm-dts-webpack-plugin:

const NpmDtsPlugin = require('npm-dts-webpack-plugin')

module.exports = {
  ......
  plugins: [
    new NpmDtsPlugin({
      logLevel: 'debug'
    })
  ],
  ......
}