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

Too large modules #45005

Closed
5 tasks done
jjangga0214 opened this issue Jul 13, 2021 · 4 comments
Closed
5 tasks done

Too large modules #45005

jjangga0214 opened this issue Jul 13, 2021 · 4 comments
Labels
Unactionable There isn't something we can do with this issue

Comments

@jjangga0214
Copy link
Contributor

jjangga0214 commented Jul 13, 2021

Suggestion

Some modules are too large.

For example, src/compiler/checker.ts has 42,797 lines, in one single file.

(Some other modules have a few thousand lines, though that MAY be viewed as suitable in some cases. )

I think that's too much and not so easy to organize and grasp, especially for contributors.

Even several IDE(e.g. vscode) extensions don't properly work for it.

Thus I suggest splitting the logic into more files.

🔍 Search Terms

large file
large module
big file
big module
long file
long module

✅ Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@MartinJohns
Copy link
Contributor

Related: #35210 / #27891.

@RyanCavanaugh RyanCavanaugh added the Unactionable There isn't something we can do with this issue label Jul 13, 2021
@RyanCavanaugh
Copy link
Member

The file is this large because it's faster to have more functions in the same closure when sharing state.

@jjangga0214
Copy link
Contributor Author

jjangga0214 commented Jul 13, 2021

@RyanCavanaugh

But 42,797 lines are insane!
I guess there are other solutions?

  1. Generate the closure as a single file: Like bundling!
    or
  2. Change language: Having to optimize THAT MUCH(e.g. 42,797 lines) may mean the initial choice of language was fundamentally wrong. We should consider porting to faster languages (e.g. C++, Rust, Go, etc).

Can you reopen the issue? Or Creating a new issue for the solutions would be better?

@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jul 14, 2021

We (the engineers on this team) all work in this file every day. If it were truly a problem that needed solving through some complex external tooling, we would have done it by now. It's not. The prioritization of our finite resources is not going to hinge on your personal distaste of a line count.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unactionable There isn't something we can do with this issue
Projects
None yet
Development

No branches or pull requests

3 participants