Skip to content
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

[Question] Can't have a "pure" typescript library. #5225

Closed
s-panferov opened this issue Oct 12, 2015 · 10 comments
Closed

[Question] Can't have a "pure" typescript library. #5225

s-panferov opened this issue Oct 12, 2015 · 10 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@s-panferov
Copy link

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:

TypeStrong/atom-typescript#560 (comment)
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/program.ts#L130

@mhegazy
Copy link
Contributor

mhegazy commented Oct 12, 2015

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 mhegazy added the Question An issue which isn't directly actionable in code label Oct 12, 2015
@s-panferov
Copy link
Author

@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?

@mhegazy
Copy link
Contributor

mhegazy commented Oct 12, 2015

so how are you building the JS file for this node module?

@s-panferov
Copy link
Author

@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?

@mhegazy
Copy link
Contributor

mhegazy commented Oct 12, 2015

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..

@s-panferov
Copy link
Author

@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:

  1. It's easy to develop several libraries in parallel, you don't need to run several watcher and recompile each library separately.
  2. My .ts files are single source of truth. When I have a ton of compiled files I ofter forget to recompile something before tests.
  3. Less compiled files in my project -> less visual noice.
  4. You can easily integrate tools like Babel and use custom webpack loaders in a single workflow.

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.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 12, 2015

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.

@s-panferov
Copy link
Author

@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.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 12, 2015

PR #4911 should remove this restriction.

@msklvsk
Copy link

msklvsk commented Oct 24, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

3 participants