feat: ACNA-3098 - allow action invocation of ES Modules / Typescript

[shazron]

closes #69
closes #42

Enables ESM and TypeScript support for action code, via webpack.

Pre-requisite PRs

• feat: add emptyDist param to buildActions aio-lib-runtime#192

Related PRs

• fix: update launch.json to skip internal/node_modules generator-aio-app#262
• fix: update launch.json to skip internal/node_modules AdobeDocs/app-builder#350

TODO

• add an action file watcher so files can be rebuilt (similar to aio app run). See this. This may introduce latency
• remove the use of the magic string for the built action code in dist, we may have to call the lib to build the actions directly, and not use aio app build. See this. We can't do this, since aio-lib-runtime uses this magic string and does not expose it
• use aio-lib-runtime to build directly
• debugging via VS Code must work properly (support source maps)
• for Typescript, you will need to npm install (devDep) typescript, ts-loader and have a custom webpack-config.js (see example project and the docs). Any includes/excludes should be in tsconfig.json. tsconfig.json should have the option sourceMap: true
• update AB Docs (see PR above)

How Has This Been Tested?

1. aio plugins install https://github.com/adobe/aio-cli-plugin-app-dev#story/ACNA-3098
2. git clone https://github.com/shazron/test-debugger.git (from this repo)
3. cd test-debugger
4. aio app dev in the cloned repo folder OR
5. step by step debug the 3 actions in Visual Studio Code via the Debug tab (put breakpoints in the CommonJS, ESM, and TypeScript actions)
6. while the command is still running, make edits to the action code, note the code gets built and updated in the log. Editing and saving while step-by-step debugging is undefined behaviour and not supported.
7. make sure that the edits are reflected in the action results after calling the actions
8. test web-src debugging
9. to uninstall this plugin: aio plugins uninstall @adobe/aio-cli-plugin-app-dev

Testing in your App

1. Update your app's .vscode/launch.json, see: https://developer.adobe.com/app-builder/docs/guides/development/#debugging-with-vs-code
2. aio plugins install https://github.com/adobe/aio-cli-plugin-app-dev#story/ACNA-3098
3. Add/edit your webpack-config.js and tsconfig.json files
4. aio app dev in the your app root OR VS Code debug via the Debug Tab
5. to uninstall this plugin: aio plugins uninstall @adobe/aio-cli-plugin-app-dev

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (65d1190) to head (45dcad4).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #87   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         7    +1     
  Lines          569       647   +78     
  Branches       125       132    +7     
=========================================
+ Hits           569       647   +78     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[moritzraho]

lgtm, but didn't test

[purplecabbage]

Do the actions all have to be built on change, previously they were only ever loaded on demand?
Has this been tested with multiple actions referencing the same code?
ie.

actions:
  myaction18open:
    function: actions/myaction/index.js
    web: 'yes'
    runtime: nodejs:18
    inputs:
      LOG_LEVEL: silly
    annotations:
      require-adobe-auth: true
      final: true
  myaction20secure:
    function: actions/myaction/index.js
    web: 'yes'
    runtime: nodejs:20
    inputs:
      LOG_LEVEL: verbose
    annotations:
      require-adobe-auth: false
      final: true

[shazron]

Do the actions all have to be built on change, previously they were only ever loaded on demand?

If you want the user to potentially wait a few seconds (ok maybe 1 second typically) before they get a response when calling a URL, for webpack to do its thing, we can make it "on-demand". We will not do it everytime of course, but we will need to set a "dirty" flag for that action to signify that a change was done - if "dirty" we need to webpack first before serving to the user.

This new behavior is exactly what we do for aio app run (minus the deploy of course - since building in this case is "deploying")

Has this been tested with multiple actions referencing the same code?

I just tested it, it works fine. This is because it will use the module.require cache, like it did previously.

[purplecabbage]

This pr can be tested directly by running:
aio plugins install https://github.com/adobe/aio-cli-plugin-app-dev.git\#story/ACNA-3098

[shazron]

@purplecabbage do we need to do anything more for this?

[purplecabbage]

In my simple project with 30 actions, this introduces a full minute wait before we accept user input. Essentially all users are forced into a build step even if their code can simply be run.

There are all kinds of ways that this could be better, for example

• the chance a user wants to call all their actions at once on startup is probably zero, yet we make them wait. They could be built on-demand, or after the web-server starts up, we could start building in the background, if an action is called before we have built it we would put it next in the build queue.
• use a pre-run hook so devs who need typescript support can have a build step, and the rest of us can still work fast.

[purplecabbage]

This breaks hot-reloading of actions, the delete require.cache[temp] is not functioning.
When we require('/dist/dx-excshell-1/actions/manyactions/sleeper-temp/') what actually gets added to the cache is ...manyactions/sleeper-temp/index.js so when we try to delete it, we need the same fully qualified path/key