Hey, sberic, thanks for responding. I hope you had a good weekend. sberic wrote 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. 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. sberic wrote Technically speaking, Adobe CEP extension development involves three separate JS environments: Okay, this does make some sense, although I'll have some difficulty separating the Browser JS and Node JS in my head, I think. sberic wrote Please be very careful using TypeScript to transpile into ExtendScript. ExtendScript itself is effectively an abandoned language and has some serious language-level bugs in it. 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.) sberic wrote I'm not really sure what to say about CommonJS vs SystemJS, myself. I guess I don't really have an opinion. Our tsconfig.json uses "es2015" for the "module" setting, but that's in support of Vue.js and Webpack. Now, to the crux of the matter. In order to use modules without SystemJS (because of its Node.js incompatibility), It seems that I would need to try Webpack again. Okay, I'm certainly willing to do so, but can you tell me how to set up the webpack.config.js file properly? Especially to handle both (or all three) JS contexts? Or maybe have it only handle the HTML Panel context while the JSX context only runs the TS compiler without Webpack? (Actually, that's a thought that I'll have to test…) I ask because, in my previous dealings with Webpack, it generates code that the ExtendScript VM doesn't handle. I'm not sure exactly where the problem is, but I do know it is probably in the comments. I've seen ExtendScript just give up when it encounters a // @ts-ignore directive, for example. So, yes, you have helped to answer some of my questions. I'll try Webpack again, but see if I can only have it work on the Panel (JS) side.
... View more