docs: import syntax requires specific '* as asl' format or exports are not found

[dmeehan1968]

Current usage documentation shows import * as asl from '@ts2asl.... when writing the source.

I prefer to use import { deploy } from '@ts2asl...' and in my initial attempt to get started did this out of habit. The result was that the stateMachines and functions were not found in the source file, and thus I couldn't attact the results to other constructs (such as an EventBridge Rule).

I've not investigated why this is the case, but it seems flaky and might break in-house style rules.

[dmeehan1968]

The following code appears to be responsible for identifying an asl expression, and this explains the specific property access convention (asl.deploy.asStateMachine/asLambda).

https://github.com/Stedi/ts2asl/blob/8d9b24c8b0da795b158d43d12d5cc8cb1c96f40d/packages/convert/src/convert/list-function-declarations.ts#L96-L107

[OlafConijn]

@dmeehan1968

thanks so much for your enthusiasm for the project and the issues you have submitted. unfortunately, the project is no longer actively maintained. feel free to fork the repository.

thanks again & have fun!

[OlafConijn]

i have added and pinned an issue here, in case you would like to discuss the discontinued maintenance of this project.

[dmeehan1968]

Hi and thanks for the heads up.

Do you have any comment on whether you found this to be a viable route for implementing ASL, or did you discover limitations?

In evaluating it I've noticed some restrictions in the current design/implementation but I'm relatively new to SFN's so not really in a position to judge whether the effort would be valuable.

[OlafConijn]

hi

I do think that a programming language like typescript is a great abstraction over ASL. if you can look past the rough edges of this tool it is a great way to learn ASL.

I think the tool was slightly ahead of its time: there are some constructs in typescript (or other general-purpose programming languages) that are hard to represent in ASL. Since then the AWS StepFunctions team has been adding new features/closing that gap. This means that this tool (as-is) has been falling behind, but over time it should become easier to create a similar tool.

if someone would want to create/continue building a tool like this, my advice would be to wait until that gap closes (it might have already significantly narrowed?).