Hello. Sorry if this issue is a double (I can't find anything relevant). Out team uses TypeScript for frontend development and we are trying to use TypeScript everywhere. So we have several libraries written fully in TypeScript.
If I understand correctly, we can't make simple import { smth } from 'pure-ts-lib/some-module'; work without having a generated some-module.d.ts file near some-module.ts. It's very inconvenient to us, because it adds an extra compilation step and more files we need to track. Is there a chance to change this behaviour to simply resolve a .ts module if any? Maybe we can control it by a compiler flag?
References:
https://github.com/TypeStrong/atom-typescript/issues/560#issuecomment-138456739
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/program.ts#L130
If I understand correctly, we can't make simple import { smth } from 'pure-ts-lib/some-module'; work without having a generated some-module.d.ts file near some-module.ts
that is not correct. the .d.ts file is only needed if you do not have a .ts file, as a matter of fact, the compiler, when resolving import * as ns from "./foo", will look for foo.ts first before looking for foo.d.ts. can you provide more information about what is going on so we can diagnose the issue.
@mhegazy my import looks like import { smth } from 'pure-ts-lib/some-module';, in other words I'm importing file some-module.ts from a node module called pure-ts-lib. In this case TypeScript requires a .d.ts file. I'm correct?
so how are you building the JS file for this node module?
@mhegazy the library pure-ts-library is written in TypeScript and I'm using it from another TypeScript project. I don't want to compile pure-ts-library to be able to use it from my project. Sorry for my bad English, do you understand what I'm talking about?
but your module pure-ts-library needs to be compiled, you need a index.jssomewhere that at runtime, will execute, correct? if so how are you building it from the .ts sources? and why not build that with --declarations enabled? if not then can you elaborate on your setup..
@mhegazy I'm building my app with webpack and https://github.com/s-panferov/awesome-typescript-loader or https://github.com/TypeStrong/ts-loader. These tools don't need any .js files to work and they track changes using webpack's watch.
Everything works correct, but atom-typescript can't provide suggestions, because it relies on TypeScript resolution rules, which deny usage of raw .ts files.
Webpack's workflow is very convenient:
.ts files are single source of truth. When I have a ton of compiled files I ofter forget to recompile something before tests.I know that this workflow is slower because we need to recompile files every time, but tools like awesome-typescript-loader have internal cache and don't re-emit non-changed modules. So the result build time is ~ the same. This workflow is much more convenient for developers. The whole my team agrees with me.
I suggest to make a compiler flag that allows to require raw .ts files from node modules. The change seems trivial.
thanks for the explanation. keep in mind that importing a .ts has some results: the file, and all its dependencies will be brought into your compilation, this can show you errors from other components, will slow down your compilation and will add global declarations from these files into your global namespace.
@mhegazy yes, I understand this consequences.
and all its dependencies will be brought into your compilation
This is what we want in 90% cases. E.g. we have a library with React components, ARUI. And we import Button component like this:
import { Button } from 'arui/button'; // resolves to 'button.ts'
And it's all we need to add a Button and it's dependencies to the project and type-check everything. If we need to import only a compile-time type (e.g. interface) from a module, TypeScript does not emit require or import declaration and webpack skips this file, so there is no runtime costs for us.
add global declarations from these files into your global namespace
All our modules are pure es6 modules and we don't have any global declarations except some files from DefinitelyTyped. And I believe that most of the modern libraries act the same way.
PR #4911 should remove this restriction.
One still can't have "pure typescript library" until #5278 gets resolved, am I right? Now getting an error "…can only be in .d.ts files…" on the nightlies.
@s-panferov, thanks for bringing this up. Strange that discussion started only 2 weeks ago, like nobody else is using similar workflows.
Most helpful comment
@mhegazy I'm building my app with webpack and https://github.com/s-panferov/awesome-typescript-loader or https://github.com/TypeStrong/ts-loader. These tools don't need any
.jsfiles to work and they track changes using webpack's watch.Everything works correct, but
atom-typescriptcan't provide suggestions, because it relies on TypeScript resolution rules, which deny usage of raw.tsfiles.Webpack's workflow is very convenient:
.tsfiles are single source of truth. When I have a ton of compiled files I ofter forget to recompile something before tests.I know that this workflow is slower because we need to recompile files every time, but tools like
awesome-typescript-loaderhave internal cache and don't re-emit non-changed modules. So the result build time is ~ the same. This workflow is much more convenient for developers. The whole my team agrees with me.I suggest to make a compiler flag that allows to require raw
.tsfiles from node modules. The change seems trivial.