search

Adobe-CEP / Samples

Code samples for CEP extensions
MIT License
972 stars 551 forks source link

Modern Typescript workflow. #147

Open braebo opened 1 year ago

braebo commented 1 year ago

I noticed the typescript example hasn't been update in 4 years. Are the types and general configuration reliable and up to date?

braebo commented 1 year ago

Also you guys are missing types for this CSInterface file. Any reason why it's not a Class? It looks like it is written in extremely legacy and outdated JS riddled with bad practices.

ErinFinnegan commented 1 year ago

Hi there!

CSInterface is likely based on ECMAScript 3 and ExtendScript, so calling it "extremely legacy" is a fair observation. I wouldn't say that the CSInterface types are missing so much as simply not provided...

Most developers of CEP panels that I know of use Types for Adobe, which is maintained by the community and it isn't complete or up-to-date, necessarily.

As CEP is slowly replaced by UXP, fortunately Adobe has started to provide more support for Typescript workflows, starting with type definitions for Photoshop (UXP) and XD.

This particular sample was probably provided by @bbb999 and @ericdrobinson working in collaboration. One of them could probably speak to how up-to-date this sample is.

ericdrobinson commented 1 year ago

Also you guys are missing types for this CSInterface file.

The CSInterface doesn't have type declarations because when you add that file to your project, the TypeScript language service has most of the information it needs to provide at least basic services.

Any reason why it's not a Class? It looks like it is written in extremely legacy and outdated JS riddled with bad practices.

Your assessment is correct (as well as @ErinFinnegan's comment). It is very much legacy. It was originally written well before things like JavaScript classes were a thing and has only had the barest of maintenance updates.

If you look at the code you'll also notice that it's simply a wrapper for some CEP-specific APIs that Adobe adds to CEP contexts. I created my own custom Type Declarations around these APIs in the event that we wanted to bypass the CSInterface altogether and simply call the APIs directly.

I do not anticipate Adobe suddenly doing an overhaul on CSInterface to modernize it - it has felt like it's been on maintenance mode for years. (I do not work for Adobe.)

I noticed the typescript example hasn't been update in 4 years. Are the types and general configuration reliable and up to date?

I haven't tested the specifics in years, but the overall outline for getting the various TypeScript contexts to work correctly should work fine (this is the configuration in the various tsconfig.json files). The type declarations in that file are also out of date and have not been maintained. Those found here are far more up-to-date.

I originally wrote the TypeScript sample as part of a larger effort to convince Adobe that they should be providing type declarations for their various application APIs. The goal was to show their immense value. That effort, along with the effort of the community to create those "Types for Adobe" and the overall increase in popularity of TypeScript within the JavaScript ecosystem appears to have finally convinced Adobe to provide an official solution... at least in their new UXP tech stack (which is only available for certain applications as yet). Hopefully they continue with these efforts and treat them as first class citizens going forward.

For CEP-based solutions, however, the community-maintained solution is your best bet. How you configure a project to support the two main JavaScript contexts is, of course, up to you. I recommend splitting your development into two "TypeScript projects" (defined by having their own root tsconfig.json) with one that uses modern tech (the browser-side) and the other that is stuck in the dark ages of ES3 with full custom type declarations (the app-side). That should provide you with a very nice CEP development setup.