Typescript 用于具有一个全局文件和单个页面文件的网站

Question

I'll preface this by saying that I've never used Typescript before, I'm tentatively experimenting with it because I really like the idea of "stricter JS". However, my knowledge of it is extremely limited at this time.

I've basically built my own library of functions for my website. A "core.js" file that is built by concatenating the files in "core/*.js". Each of those files would define properties on a global window.myLib object.

Then, each page has its own JS file that handles events for that particular page. They can call things from the global window.myLib .

Each page then has two script files:

<script src="/core.js"></script>
<script src="/js/page_name_here.js"></script>

And this works quite nicely.

I'm using VSCode for development and have set up a "globals.d.ts" file that lists what properties and functions are defined in the library, which allows Intellisense to provide very useful tooltips and hints on what is where.

So I'm wanting to "level up" by actually going full Typescript with this, and having tsc compile my JS files.

Step 1 would be compiling the library. At the moment this is done PHP-side(,) by checking file modification times and, if necessary. concatenating the files and sending the result off to closure-compiler? I believe this is how I should do it in TS -- is this correct?

window.myLib = {}
window.myLib.eventHandlers = require("./core/event-handlers.ts")
window.myLib.AJAX = require("./core/ajax.ts")
// ...

If not, what is correct for building a file like this?

Step 2 then is the individual page files. I think since I've already done the work of defining "globals.d.ts" with the library functions, I don't have to do anything in particular to have those files be able to use library functions. tsc should be able to read the definitions and use them whenever I refer to window.myLib . Am I correct on that, or do I actually need to reference the core file in some way?

Any further pointers aside from these two questions would be much appreciated as well. I'm very eager to try something new (to me) but there's a bit of a massive leap between "just write the JS and the browser will figure it out" and "you're writing for a compiler now!"

Answer 1

As for the 'TS ==> JS' compile step, I strongly suggest you take a look at what babel has to offer. It plays quite nicely with the TS compiler through its plugin architecture, and can be integrated in most (if not all) modern build tools like webpack .

Warning : setting up a full webpack-with-babel-wih-typescript project can be very time-consuming and feel tedious. You might hit the point where you feel that things are getting overly complex, for you 'just' wanted to do a website in TypeScript.

Not sure if you are doing this more as a learning project (where the quality of the final output is not the main concern), or if you want to use TypeScript and get real . In the latter case, I suggest taking a look at one of the popular frontend frameworks. Even if you want to have a fully static site, they offer solutions to modularity, and offer a (more or less) out-of-the-box TypeScript experience.

You might want to take a look at:

• NuxtJs , which is based on the (somewhat easier-to-lean-than-react) Vue.js and also supports TypeScript
• Gatsbyjs , the react -equivalent to nuxtjs. I have created a starter with TypeScript, eslint+prettier, and a decent vscode config.
• Svelte , which claims to love TypeScript and has gained enough hype to be taken seriously. Probably more fun than learning react, but not as mature.
• any of the other popular web frameworks that support TS. There are plenty. Just probably don't code something yourself, if you care about your hours-to-output ratio.

Each of those frameworks handles modularity slightly different, but for me it all boils down to:

• write small, modular functions with no implicit dependencies (eg don't depend on functions living on the window object.) and a single responsibility.
• import the functions (using TypeScripts import syntax ) wherever you need them in your components
• let the framework do the rest, eg compiling, bundling, code splitting … the hard stuff

TL;DR: if you want to work on a (potentially) real project, use a framework.