This is very similar to #8305.
In our world we are using webpack to bundle our typescript library which has many levels of nesting. For example:
mylib\
services\
index.ts
service1.ts
foo\
bar\
index.ts
barImpl.ts
At the moment our current approach is to export everything into one top-level index.ts which means consumers lose the nesting and we have to write the .d.ts files ourselves
Ideally we'd like consumers to import modules like this (and avoid a single index.ts file at the top level that exports everything in a non-nested structure):
import { service1 } from 'myLib/services
However it is not obvious from the documentation how to write a .d.ts file that supports this layout when this is how the webpack bundle is structured. As a second part, how can I have TS auto-generate the .d.ts files for us so that we can have a single definition file for our bundled JS
As a second part, how can I have TS auto-generate the .d.ts files for us so that we can have a single definition file for our bundled JS
Suggestion: Separate what webpack does with what tsc does:
.ts
files to .js
+ .d.ts
files. .js
files in a bundle.js
This way your published module should contain : bundle.js
, all the .js
, all the .d.ts
And people get to chose if they use bundle.js
(not webpack user) or all the .js + all the .d.ts
(webpack user)
I might be wrong :rose:
Does my sample in https://github.com/Microsoft/TypeScript/issues/8305#issuecomment-214815674 address the issue? if no, why not?
@mhegazy not exactly.
Your sample shows how to consume npm-libraries. As a library developer, using webpack to bundle, what is the best process to expose modules that "match" the folder listing and at the same time generate a single .d.ts file that includes the definitions for these bundled javascript modules.
i see. that is not a supported feature now. i would assume you want to have a --declarationFile
that will bundle all your module declarations, but not your js output (currently --outFile
bundles both .js and .d.ts output). is this accurate?
Yes, I think that is accurate. I think this is a common workflow, where TS developers will bundle a production bundle but still want to provide a d.ts
file for other typescript consumers.
Happy to take advice on other alternatives.
thanks, updating the title to reflect the request.
PRs are welcomed.
Any updates on this?
I'm just realizing that Typescript isn't very node.js developer friendly.
I'm just realizing that Typescript isn't very node.js developer friendly.
curious to know why is that.
@mhegazy I came to this issue thinking something similar, but that TypeScript is not very JS library developer friendly. It is not easy or obvious how to create a single .js
file to use as a library on the web from several .ts
classes, while this is trivial to do with plain JavaScript and requires no tools. TypeScript seems to require a lot of external tools to make projects like that work. In this case at least webpack is necessary to produce such single-file output, which really surprised me going in to TypeScript. (Or if not webpack, writing a script to strip the import/export from each file and concat all your .ts
files before tsc
runs)
The issue here for developers of web libraries is the other side of that coin. If I want to create a single .js
file to use on the web as a library, I have to do something totally different to make a single .d.ts
file. Specifying outFile
won't work if your module is "commonjs"
, so something like declarationOutFile
might be nice.
Any update on this?
Any update on this?
The issue is marked as Accepting PRs
. so PRs are welcomed.
Monthly checking for any updates on this :)
Pwetty pwetty pweaseee
New year update?
Closing as a dupe of #4433
Most helpful comment
Any updates on this?