cloudform-types access

[fhewitt]

Since 3.0.0, to be able to use CloudForm types, I need to add cloudform-types to my dependencies in addition of cloudform. It's not really bad, but it looks like an unwanted regression.

I see the utility of being able to import cloudform-types without cloudform, but the contrary seems weird considering they are strongly related and that cloudform depend on the types already.

Should these types be re-exported from CloudForm?

[NOtherDev]

This is what I do in the cloudform's index:
export * from 'cloudform-types'

In my project I am able to use it directly, without cloudform-types dependency:
import cloudform, {Fn, SNS, SQS} from 'cloudform'

Can you describe why isn't this working for you?

[fhewitt]

You're right... After further investigation, I realize it's a feature request, not a regression...

I have some functions that return reusable parts. For example, I don't want to repeat what is the default cache behaviour for all my CloudFronts. The types that I use that cause me issues:
ElasticBeanstalk.ConfigurationTemplate.ConfigurationOptionSetting
CloudFront.Distribution.CacheBehavior
CloudFront.Distribution.DefaultCacheBehavior

I realize that theses types where never directly exported by CloudForm (and still not exported by cloudform-types) and I had deactivated the no-submodule-imports to access them prior to 3.0.0. Which is not recommended exactly because the path can disappear/change without deprecation notice.

Then, I tried another approach with half success. I can extend it

import { CloudFront } from 'cloudform';
class NoCacheBehavior extends CloudFront.Distribution.CacheBehaviour {

and I can instantiate it too with new CloudFront.Distribution.CacheBehavior(params);

But I can't use it for typing: noCacheBehavior(): CloudFront.Distribution.DefaultCacheBehaviour {, let noCache: CloudFront.Distribution.DefaultCacheBehaviour; and class Testing extends Array<ElasticBeanstalk.ConfigurationTemplate.ConfigurationOptionSetting> { raise a "cannot find namespace 'CloudFront'" error.

The last case could be useful, but the current situation leave a lot of acceptable workaround (I'm even not sure if the third case should not considered as a TypeScript issue considering the class can be extended and instantiated)

[NOtherDev]

OK, I see the point. CloudFront is exported as a const holding fields typed with classes. You can instantiate it because it resolves to a class. But you can't use it as a type because due to that const, it goes "down" into objects' world, not types. I guess it should be exported as a namespace - I'll try to do that. I'm only wondering are there any side effects of that change...

[NOtherDev]

@fhewitt Have a look at the changes in the namespaces branch. I did it by hand as a quick PoC, but it seems to work fine (see main index.ts for example) and in a backward-compatible manner. WDYT?

[fhewitt]

The resulting code looks great and the change from const to namespace seems the proper approach. Now I've never used typscript namespaces so I'm proably not the best one to review the PR.

[NOtherDev]

I've implemented this change in v4.0 and it seems to work fine. Please reopen if it doesn't work for you.