Move writer out of the checker into another file.

[sandersn]

This is, I hope, the first step in converting the compiler to use modules. For now I want to address the practical problem of the checker's growth, which is on track to hit 20,000 lines soon. I moved the writer code into a separate file (typeToString et al), using the create* pattern which is eerily similar to real modules.

After this proof-of-concept, I plan to move more chunks of code into separate files, then look at converting to ES6 modules afterward.

[DanielRosenwasser]

Since you only call this once, it might be beneficial to pass an arguments bag - especially for something like () => nothingType where it's not obvious what this is used for

[sandersn]

You mean, basically surround the whole thing with {} and add getNothingType: in front of () => nothingType? That seems reasonable, especially if these collections get less ad-hoc and might be re-used between other 'modules'.

[sandersn]

done. It means I have to repeat the names while defining createWriter, but that's not too bad:

createWriter({f, g, h}: { f: () => number, ... }) ...

[DanielRosenwasser]

You could just create a separate interface for the type but yeah

[sandersn]

I'll wait on the interfaces until I've done a few more of these. I expect the interfaces will split up as they're used by multiple modules.

[basarat]

the first step in converting the compiler to use modules

I always thought you guys had a super awesome editor that could handle such files with grace 😄 🌹

[sandersn]

@basarat we do. VSCode is still decently fast on checker.ts. :)

But I use emacs to make sure our language service stays speedy with 3rd party editors. checker.ts has pretty long intellisense delays with emacs and Sublime.

Also github's UI behaves badly with files over 10,000 lines long.

[sandersn]

@vladima can you take a look at this module-esque style from a performance perspective?

[ahejlsberg]

@sandersn If we're going to do work in this area, let's first take a look at cleaning up the buildXXXDisplay functions which have become really messy.

[sandersn]

Sure, what did you have in mind?

I'm actually more interested in shrinking checker below 10,000 lines by moving coherent, rarely changing code into separate files. The buildXXXDisplay functions were just the first group I did as proof that I could break out module-like things without a performance hit.

So if this modular approach is a good one, I'd rather merge this branch and then do the cleanup in a separate branch.

[ahejlsberg]

Let's discuss offline. I think we should have an all up plan before we embark on restructuring individual subsystems.

[mhegazy]

@sandersn is this still needed?

[sandersn]

Yes, I just haven't had time to sit down with @ahejlsberg and @DanielRosenwasser to come up with a plan. @andy-ms carried out a similar project for services recently, but it's needed even more for the compiler proper since the checker's over a megabyte now.

[sandersn]

Worthwhile to note that @weswigham validated this approach by writing much of his code this summer in this style.

[mhegazy]

Closing for the lack of activity. Please feel free to reopen.

[masaeedu]

@mhegazy Now that the checker is big enough that you can't even display it in several places in Github anymore, perhaps it is a good idea to revisit this? There are large swathes of checker.ts that haven't been touched since the project was migrated in 2014.

[mhegazy]

i think we need a more comprehensive solution here. breaking the writer out does not solve this issue.

[masaeedu]

@mhegazy Sure, I just happened upon this while looking for issues referring to breaking up checker.ts. Is there already a canonical issue to track this?

[mhegazy]

Is there already a canonical issue to track this?

not that i am aware of.