Create an official typescript and typescript-compiler packages

[Urigo]

Create an official typescript and typescript-compiler packages and talk with and deprecate - https://github.com/meteor-typescript/meteor-typescript-compiler
Follow also the typescript label.
Also, merge https://github.com/meteor-typescript/meteor-typescript-libs into the typescript package

Beta version:
Last version: barbatus:typescript@0.2.0-beta.13
Main repo: https://github.com/barbatus/typescript
Packages involved: https://github.com/barbatus/typescript-compiler, https://github.com/barbatus/meteor-typescript, https://github.com/barbatus/typescript-runtime

[barbatus]

It's actually bad idea to install typings via any package.
First of all, this particular package meteor-typescript-libs has bunch of definitions that already available from either DefinitelyTyped or typings registry. In any case, it's a waste of time keep updating them in the package whereas they are updated constantly by the authors or community in the global repos.

For other definitions not available globally, we could create a Github repo for each particular definitions and recommend to install them using typings tool, while we'll send PR to include them into the global typings registry. This tool can install definitions from a Github repo, NPM package, or even HTTP path.

[Urigo]

ok sounds good about the typings libs repo.
let's add @orefalo and @jasonparekh to the discussion.

[Urigo]

we also want to add a chapter on Typescript in the Meteor guide

[orefalo]

adding @fullflavedave

perfectly fine with the idea.

[fullflavedave]

Not having much context on all this, it looks like this is part of an awesome effort that could greatly improve the experience of using TypeScript with Meteor. Are you all creating a new build compiler package that will make using TypeScript with Meteor almost as easy as using CoffeeScript?

I'm happy to deprecate meteor-typescript-libs if a better solution makes sense.

[barbatus]

beta version of the future typescript packages is published as barbatus:typescript@0.1.0-beta.1

Packages involved:

• meteor-typescript NPM package https://github.com/barbatus/meteor-typescript
• typescript-compiler package https://github.com/barbatus/typesctipt-compiler
• typescript package itself https://github.com/barbatus/typescript

UPD: latest version barbatus:typescript@0.2.0-beta.4

[D1no]

Hey, I just saw this repo due to your comment.

How are multiple tsconfig's handled? TypeScript 1.8 implemented the handling of tsconfig files closest in the path of a ts file. This is especially important for isomorphic code, because definition files, declaring i.e. a class "Plugin", are completely different things i.e. on the client vs. the server. See here a feature illustration that was implemented in Webstorm: https://youtrack.jetbrains.com/issue/WEB-17472#comment=27-1098038

Also, last year I investigated what is necessary to bring TypeScript to meteor (we stopped because of missing module support and currently use webpack), for which I wanted explicitly TypeScripts incremental build feature because TypeScript code bases can become rather large for which the compile method creates a lot of overhead. A good way is to use the native language service API. You can read up on it here: microsoft/TypeScript#4382 (comment)

[barbatus]

@D1no
While multiple configs feature is likely doable using current state of the Meteor compiler API , it’ll significantly overcomplicates things.
First off, we are trying to create/test some initial version, and then will update it gradually. Not to mention that tsconfig.json itself in different IDE has multiple additional options, for example, filesGlob is specific to WebStorm and Atom. At the same time, original tsconfig.json is quite simple and has only “files” options. I see the right strategy is to stick to TypeScript updates itself since, I believe, features, like mentioned filesGlob or even multiple configs, will be implemented in some way in TypeScript itself one day . We, of course, might implement them faster in case they were requested by multiple users and/or certainly makes sense for Meteor.
BTW, isomorphic ( in the Meteor context) i believe means when some code base has same API whether on the client or server if it’s supposed to work both on the client/serve. Otherwise, if APIs are different and can conflict in a definition file, I don’t see why methods/classes can't be renamed to contain, say, ‘client’/‘server’ identifications to outline differences and avoid conflicts.

About the last one. Yes, I plan to implement some in-memory files cache to avoid reading overhead.

[Urigo]

@D1no I agree with @barbatus approach and hope to get a major release for that package soon without that feature.
But, if you like to collaborate together on a branch with this feature I would love to do that

[D1no]

Hey @barbatus, thanks for your reply! I tried to find it - but couldn't - that TypeScript (the language service api) already supports multiple tsconfig files by recursively running from a file down the folder structure picking the first tsconfig it finds. Identical behaviour to what is found in the webstorm ticket. But maybe I am wrong.

Also, I fully embrace that this is prototyping for a functional compiler and the TypeScript project is far from simple. I already did a tech evaluation a while back on it... of course it is not so present in my mind as it should be. But here some feedback to your reply - stuff you may know - which may leap up deep into further versions.

(Edit: I didn’t finish the comment last night. In retrospect, could have been a blog post... typescript in isomorphic environments is still a pain.)

Importance of tsconfig.json

The tsconifg.json has far more official options than just files. For meteor, the important one here is the flag --noLib that prevents the inclusion of lib.d.tsand provides the ability to define additional d.ts typings. So you need different tsconfig's to not only specify compile targets but also typing configurations. Why?

Beware, lib.d.ts is included by default

By default, the TypeScript compiler includes a lib.d.ts that tries to be magic by typing a whole bunch of global variables that you may find in the DOM; ES5, ES6 & ES7 Specs, Webworkers etc. If those global typings are included by default, you'll see that you get a bunch of errors when trying to use TypeScript on the Server because there are many Globals/Classes etc. typed through the standard lib, that work completely different (wrong shape) or collide with additional typings of i.e. node.d.ts or meteor.d.ts. The same applies to other libraries & compile targets.

Danger of double Typing

This is i.e. the case with Plugin. It is typed in dom.generated.d.ts which is part of lib.d.ts. But Plugin is also a global Class of Meteor - as you know (the build plugin). So if you used meteor.d.ts and the standard lib together; you would get a bunch of conflicting compile errors for your use of Plugin because it is both defined as a DOM Global and a Meteor Global on the server. That is also the reason why the meteor typescript libs have been split up into server, client, common etc (https://github.com/meteor-typescript/meteor-typescript-libs/issues/25).

Plugin is just one of many many examples where the same class/global/method names mean completely different things depending on the build target (client web / cordova / webworkers / etc. - server node / meteor / test runner).

Target dependent Typing

So in order to use TypeScript effectively, you really need to slim down the default typings and handle them manually. Prevent the inclusion of lib.d.ts with the --noLib compiler flag and re-include parts of them depending on the section of the app while not breaking the sharing of “common” code. In a best case, while IDE's still understand what's going on (= they need to see tsconfigs to adjust the IDE level diagnostics).

I.e. the code on the server should not have DOM typings but include core.d.ts. On the client, typings of es7.d.ts are probably overhead. Same for node, meteor etc typings. Which exact libs needs to be investigated. Because what doesn't work (mentioned above): You can not "re-type" classes because d.ts do not overwrite each other.

Language Service API as a quick way to get all functionality

The language Service API is capable at managing all files in a project. It is intended for fast re-transpiles. As a reference TypeStrong (ts-loader for webpack) implemented the language service api, though it is not an IDE, because the simple compile/transpile method falls apart on multi-file bases. Or getting corrupted results due to missing diagnostics. Using the language service api can be a quick win because it includes everything like the management of typings, in-memory caching, diagnostics etc. etc. Saving one to re-build everything around the transpile method, which you seem are about to do. No value judgment; it can make sense - idk

A reference how to do that can be found here (as mentioned above): microsoft/TypeScript#4382 (comment)

Technically, the vanilla Language Service API expects file system access. But as TypeStrong did with its getScriptSnapshot method (linked through the comment above) it is replacing the file-system with an adapter into webpacks file management. The same can most likely be done with meteor -> simply giving the L.S. API access to meteors “file structure” by bridging file access inside the compiler. Provide a tsconfig. Done.

So this is a proposal to bridge to the Language Service API instead of re-creating everything around the transpile method. This would also mean, that typescript is easier to update. But I have to agree, it is really not that easy to get a first grasp of the monolithic structure.

I loosely consult two large projects that use TypeScript through and through and after a long evaluation and a few failed attempts to bring TypeScript to meteor, webpack was chosen.

I lobby every now and then for the support of TypeScript (meteor/guide#41 (comment)). I also own the atmosphere.com/typescript Org (the experimental package has been pulled; but happy to include solid solutions that honer the ts team) and personally planned to revisit the issue in the summer. Though of course, atmosphere seems full of typescript packages now… and I am a little out of date on the issue

[barbatus]

Some quick updates on the last changes in the compiler and on the progress in general.

@D1no meteor-typescript compiler doesn’t make any difference between TypeScript declaration files and general TypeScript files, which means all TS files will be processed and
get into an architecturally-specific (elaborated further why) AST if they are placed in any folder within a Meteor app’s folder structure. At the same time, it makes difference which Meteor architecture each file to be processed has. So if a declaration file lies in the server folder, for example, it will be taken into account only for server TS files only, if it’s in the client folder - only for the client’s files, and lastly if it’s at the root level - it will be parsed for both architectures.
Regarding TypeScript default libraries, as I can see in the TypeScript repo now, they have refactored some default libraries in order to (as it seems to me) to make separation
between definitions of the Node and browsers environments clearer. For example, Plugin was moved to lib.dom.d.ts. While basic lib.d.ts still has some definitions specific to the browsers only but
they don’t seem to intersect with the Node and Meteor. If somebody be facing an issue with that in the future (which I doubt), we could create own copies of the default libs with even clearer separation - it’s not hard.

@mattmccutchen As to diagnostics re-evaluation when file references change, it should work now. Please verify that it works for you as well. One note though on rendering files barely in the automatic way when they don't export anything, i.e., what we're discussing some time ago. I was forced to remove this feature (content checking for exports), and leave only one way, i.e. when module: none is set in the config, to turn on TypeScript internal modules. The reasons behind that is to make available imports like import ./foo for ES6 modules (i.e., when whole file is being imported). In other words, file foo.ts might not have exports but, at the same time, it still can be imported wholly using ES6 modules. If it’s rendered with bare set to true, it’s stripped of any modules information, therefore - no way to import ./foo. Since ES6 modules (CommonJS particularly) has more priority for Meteor 1.3, I decided to leave only module: none way for TypeScript internal modules.

[jacobdr]

Thanks for the updates @barbatus

I know this might be a little bit of an annoying question, but can you provide more context around @Urigo's first post in this thread and give a brief explanation of how the current meteortypescript:compiler relates to all of the other packages listed here, and what the future plan is.

I have spent the past half hour trying to answer a basic question: what project can I fork to bump the official typescript package version (tsc)?

However, I feel like I am going a bit mad tab-jumping to a bunch of different repositories, and its a little bit hard to get the "Big Picture" of Typescript in Meteor.

[barbatus]

@jacobdr meteortypescript:compiler is another one TypeScript package which doesn't relate directly to the current effort going on in the this issue. I have though repo access to meteortypescript:compiler and plan in the near future to add (imply) https://github.com/barbatus/typescript package there in order to test it on a bigger auditory. After, if https://github.com/barbatus/typescript turns out to be ok for most users, I have plans to deprecate meteortypescript:compiler.

[Urigo]

@barbatus I think @jacobdr makes a good point that we haven't documented well the goal and relashanships of all the packages that form the new Typescript package.

I think we should specify in their readme files what they do, how they related to each other and how does it relate to the ecmascript package model:

• https://github.com/barbatus/typescript
• https://github.com/barbatus/meteor-typescript
• https://github.com/barbatus/typescript-runtime
• https://github.com/barbatus/typescript-compiler

We can also update and specify that in the first comment of this issue

[jacobdr]

Sounds good. To be clear: as a Typescript consumer looking for the latest Meteor build compiler, I want to meteor add barbatus:typescript to my project, correct? (With the aim of deprecating or pointing meteortypescript:compiler to the new effort?)

I would be happy to contribute to the documentation/standardization of packages effort, but to do so I probably need some context on the topic. Is there something in the Angular-Meteor design docs or Trello that you guys might be able to point me to?

[barbatus]

@jacobdr I've changed meteortypescript:compiler to use barbatus:typescript recently.
The source code to my mind is quite simple and easy to get into. I've also added some commentaries there recently, and plan to add more. So you could try to look into the source code and learn.
Package structure is briefly described here https://github.com/barbatus/typescript#package-structure.

[barbatus]

@fullflavedave Can you please look/approve Definitelytyped PR?

[fullflavedave]

I just approved it, but a few, easily fixed lines (my fault) in the test file are holding up the Travis CI build process.

[ndarilek]

TypeScript n00b here: I had a bunch of sections like the following in my project: ``` declare module "meteor/meteor" { let Meteor: any export Meteor } ``` This let me `import {Meteor} from "meteor/meteor"` until the definitions were updated. Now that they are, when I install this module and remove the above block, I still get: `server/stripe.ts (1, 22): Cannot find module 'meteor/meteor'.` What am I not getting this time? :) Do these type definitions not include what is needed to import Meteor modules using ES2015 syntax? Thanks.

[barbatus]

@ndarilek it's not updated yet

[ndarilek]

Ah, got it. I did "typings install --ambient --save meteor" and got a definition that claims to be for 1.3. Also, the deprecation warning went away. Am I installing the wrong definition, or is the update only partial? Thanks.

[barbatus]

@ndarilek Here is that PR DefinitelyTyped/DefinitelyTyped#9113.
It needs an approval from couple of more people.
I think that claim is wrong, it's still for Meteor 1.2.

[fullflavedave]

Yes -- the 1.3 claim is wrong. The previous definitions were automatically generated from the official Meteor 1.3 JSDocs JSON file, but the necessary additions were not made for Meteor 1.3 imports and exports.

[barbatus]

@fullflavedave I've recently started moving Meteor and major packages' typings to dedicated repos under one organization, i.e. check out https://github.com/meteor-typings and https://github.com/meteor-typings/meteor for more info. I think it's time to deprecate https://github.com/meteor-typescript/meteor-typescript-libs since most Meteor specific typings have been moved there, to my mind, while others - either deprecated or third part libs typings, which already exist and are maintained in other registries (either DefinitelyTyped or typings's registry).

BTW, if you still have desire to help with typings, I could invite you to the organization.

[fullflavedave]

Great work! I'll deprecate https://github.com/meteor-typescript/meteor-typescript-libs and reference the typings and DefinitelyTyped registries in the README.

I'd love to help out with typings, since I use TypeScript and Meteor everyday for my work and occasionally find random improvements for the definitions.

Thanks for all of your good work on this!

[orefalo]

 Looks good, will give it a try in a few weeks when I can find free time.

Olivier

On Wednesday, June 8, 2016 5:59 AM, Alex <notifications@github.com> wrote:

@fullflavedave I've recently started moving Meteor and major packages' typings to dedicated repos under one organization, i.e. check out https://github.com/meteor-typings and https://github.com/meteor-typings/meteor for more info. I think it's time to deprecate https://github.com/meteor-typescript/meteor-typescript-libs since most Meteor specific typings have been moved to my mind, while others - either deprecated or third part libs typings, which already exist and is maintained in other registries (either DefinitelyTyped or typings's registry).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[fullflavedave]

I just saw this announcement: https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/. So would it make sense to try to point the meteor definitions at https://www.npmjs.com/package/@types/meteor to the newest meteor-typings definitions or temporarily update the definitions on the DefinitelyTyped branch that it's pulling from (or perhaps both)?

[barbatus]

@fullflavedave It seems to be intended for NPMs. Since Meteor doesn't come as NPM, not sure it's going to work for it. typings for example is much more flexible in that providing different installation options, including separation of the browser and node versions.

[barbatus]

Thanks all for the awesome suggestions/help etc (@mattmccutchen, @D1no, @fullflavedave etc)!
Discussions/issues from now on are here - https://github.com/barbatus/typescript