Modern Tools and ExtendScript
Earlier this week, Bruce Bullis integrated a pull request into the CEP Samples repository that included a new Sample called TypeScript. TypeScript is a language that "transpiles" into JavaScript and JavaScript-based languages (e.g. ExtendScript). It can also be configured in certain environments (e.g. Visual Studio Code) to provide normal JavaScript (and, it turns out, ExtendScript) development with helpful type checking and IntelliSense/autocompletion support. Here's an example:
Open the PProPanel-vscode folder in Visual Studio Code (or other TypeScript-aware IDEs?), open up the Premiere.jsx file, and simply begin typing. The environment is already set up to provide rich IntelliSense support.
Powered By TypeScript Declaration Files and JSDoc
The environment has to get information about the types from somewhere, right? The type information is identified by the TypeScript system in the following ways:
- In the Panel JavaScript Environment:
- Uses the TypeScript-provided ES5 type information.
- Sources JSDoc comments for type information. This is how CSInterface.js, for example, is parsed!
- In the App ExtendScript Environment:
- Uses the TypeScript-provided ES5 type information (ES3 is coming - when available, it will be switched to use that!).
- Uses custom Type Declaration files (included within the sample here) to help make the IDE aware of what types are available, as well as documentation!
- Sources JSDoc comments for type information.
Beyond this, TypeScript is capable of type inference (set var x = 5; and the IDE will infer that x is a number). For more on how TypeScript does all of this, see this document.
Inline ExtendScript and PremierPro API Documentation
The declaration files included in the sample are currently incomplete, but Bruce Bullis has indicated interest in helping to fill in the blanks. These files are an improvement over the current documentation in that they can be [more] easily read on the web (don't need to be downloaded and opened in a browser) and also power in-line documentation and suggestions (as in the above gif)!
Writing in TypeScript
As configured, the sample does not actually assume that you will be writing in TypeScript and transpiling to JavaScript, but that you are simply writing JavaScript/ExtendScript. If you wish to use this feature, you will have to configure your IDE to do so (Visual Studio Code, Webstorm, Sublime Text, etc.).
Writing in NEW JavaScript
It should also be noted that TypeScript can transpile from new JavaScript to old JavaScript. This may not seem all that interesting except that you could use the latest ES6 features to write code for both your panel JavaScript or your app ExtendScript. These would be transpiled into platform-compatible versions: target: "es5" for panel and target: "es3" for ExtendScript!
As with TypeScript, this use-case would require setting up the TypeScript compiler.
Debugging In Visual Studio Code
This sample also contains configuration settings to allow debugging of the panel (HTML) environment directly in Visual Studio Code, rather than through a Chrome browser. See:
Questions? Comments? Ask/post away!
1 Correct answer
Sturm359 wrote
For reference, I am using PHPStorm (since other projects I work on use Laravel and PHPStorm appears to handle front-end development just fine, I see no need to also purchase WebStorm).
If you haven't checked it out yet, I would highly recommend giving Visual Studio Code a test run. It is fully integrated with TypeScript out of the box and makes working with the language a breeze.
Sturm359 wrote
Since developing an Adobe CEP extension requires two separate JS environments
Technically
...
29
Replies
Sturm359 wrote
I have used VSCode in the past and I did, indeed, like it. However, I needed something more for working with Laravel projects, thus I purchased PHPStorm a while back and fell in love with its capabilities. It also handles TS out-of-the-box easily. Now, I wouldn't mind trying VSCode again, but I don't think the IDE is really the issue at hand, I think.
Yep! I've not used PHPStorm and had no idea it had tight TS integration. I'm glad to hear that PHPStorm is working so well! Please disregard the VSCode suggestion 
Sturm359 wrote
The reason why I didn't really want to write ExtendScript (AES) natively is that I did so years ago and wound up with scripts that are thousands of lines long with spaghetti code all over the place. I have to maintain it and it becomes more and more difficult year after year. After having learned some OOP principles, it makes more sense for me to re-do those old scripts using those principles—classes, inheritance, etc. And if I can leverage external modules, then I can make the code perhaps a bit more modular as well as easier to maintain and build upon in the future. Would you think so?
I understand the inherent issues that could arise with transpiling to such an old language, however, I don't really plan on doing anything super-fancy. I only know the basics of OOP and don't plan on using all of the features of TypeScript. Heck, I don't even understand all of them. And you can bet that I'll be doing plenty of testing before deploying. (It's for our internal company's use only.)
To be fair, you can write non-spaghetti code ExtendScript (or ES3 compatible JavaScript), it just takes discipline as you have to be careful about structuring your code. That said, I do agree that TypeScript can dramatically simplify things for you, improving maintainability, readability, and, perhaps most importantly, safety.
I would urge you to be extra vigilant in your testing as you may quickly find yourself using more advanced features of TypeScript. Not only will your continued usage of the language make you more comfortable, but your Google searches for help with a problem will likely start turning up elegant solutions on Stack Overflow that make use of those features. Transpiled TypeScript has not been thoroughly tested against the ExtendScript Virtual Machine. I found the bug I linked to in my previous post while investigating an issue reported by someone else who'd tried to transpile TypeScript->ExtendScript and discovered that Generators simply broke for him.
Regardless, if you're vigilant with your testing, then you should be fine! If you happen across any further bugs, please do share them with the class! 
Sturm359 wrote
Using Webpack only on the Panel side and the plain TS compiler on the JSX side seems to have tamed this unruly beast. I am finally able to use Node.js' FS module, jQuery, etc. without a problem. Whew!
Awesome! Very glad to hear you were able to get this working. Quick question: did you end up enabling the mixed context?
Sturm359 wrote
On another thread, I was told that CSInterface has its own API for accessing the filesystem. I wonder which is more efficient. Perhaps I'll try out both, now that it seems I can access both.
Yup! If all you need is file system access, you can probably get away with just using the CSInterface, rather looking to NodeJS at all.
Sturm359 wrote
Admittedly, though, this all does seem quite convoluted, when I was expecting something a bit more elegant. But, hey, if this is the best way to use TypeScript with CEP, then I'll take it!
To be fair, the original forum post was written to describe how you could setup your environment to take advantage of TypeScript's language services to assist in writing JavaScript/ExtendScript directly. The goal was to show how you could enable TypeScript-enabled features (static analysis, IntelliSense, autocomplete, etc.) for CEP development.
The post does mention that writing TypeScript directly is possible, but that "you will have to configure your IDE to do so" (setup the compiler, etc.). That was a bit beyond the scope of the initial post but it's good to have the discussion here in the comments! Hopefully the examples you linked will provide helpful hints to others trying to get a project started!
That did it.
Using Webpack only on the Panel side and the plain TS compiler on the JSX side seems to have tamed this unruly beast. I am finally able to use Node.js' FS module, jQuery, etc. without a problem. Whew! Here's how it stands now.
On another thread, I was told that CSInterface has its own API for accessing the filesystem. I wonder which is more efficient. Perhaps I'll try out both, now that it seems I can access both. Admittedly, though, this all does seem quite convoluted, when I was expecting something a bit more elegant. But, hey, if this is the best way to use TypeScript with CEP, then I'll take it! 
Nevertheless, thank you so much, sberic for your help!
AdChoices