js07 / pd-convert-actions Goto Github PK

, which may not support all module.exports as named exports.

CommonJS modules can always be imported via the default export, for example using:

import pkg from 'bar';
const { foo } = pkg;

Suggestion: Import CommonJS modules that don't support named exports via the default export.

• Convert require("@pipedreamhq/platform") to require("@pipedream/platform")
• Pass $ as the first argument of @pipedream/platform axios

For example:
Before

return await require("@pipedreamhq/platform").axios(this, {

After

  async run({ $ }) {
    return await require("@pipedream/platform").axios($, {

• $send -> $.send
• $respond -> $.respond
• $end -> $.flow.exit

Component action docs: https://pipedream.com/docs/components/api/#actions

Currently, legacy actions must include a namespace, title, description, version, code_config, code_raw, and hashId to be converted to a component action.

Support converting legacy actions from only the code_raw so that code steps in workflows can be converted using only the code. Allow the other parameters to be optional.

E.g.
"enum":["html"","markdown"] -> options: ["html", "markdown"]

When a legacy code contains this.$checkpoint:

• Convert this.$checkpoint to this.db
• Add a db prop to the components props

For example:

In the legacy workflow builder, this prop's label is "AnonymousId`:

In the legacy workflow builder, this prop's label is "Email address":

(eg. mailchimp-add_or_update_subscriber)

E.g.

- // legacy_hash_id: "a_poikPY"
+ // legacy_hash_id: a_poikPY

Something like:

• // Action converted from <hash_id> or
• // old_action_id:a_abc123

This is low priority since components can be CommonJS, and ESM-only packages would have also broken legacy actions.

• $attachments -> steps.trigger.context.attachments
• steps -> steps 😃
• event -> steps.trigger.event
• $checkpoint (no replacement yet)
• this.$checkpoint

In converted actions, references to named exports after $.export are left unconverted (i.e., referencing a variable that was removed). For example:

In legacy action:

this.projects = [];
this.projects.push("project1");
return this.projects;

In converted action (error ❌):

$.export("projects", []);
this.projects.push("project1");
return this.projects;

Desired ✅:

let projects = [];
projects.push("project1");
$.export("projects", projects);
return projects;

In actions.csv, the DEFAULT_NAMESPACE for the Cloudinary app's Upload Media Asset action is cloudinary_upload_media_asset. The app slug (cloudinary) is included in the namespace.

Which should the generated component key for this action be?

• key: "cloudinary-cloudinary_upload_media_asset" or
• key: "cloudinary-upload_media_asset"

The latter follows Pipedream's component key pattern guidelines.

Errors:

• Component prop cells must have a label. See https://pipedream.com/docs/components/guidelines/#props eslint(pipedream/props-label)
  Reason: Component props are generated without labels

• Component prop cells must have a description. See https://pipedream.com/docs/components/guidelines/#props eslint (pipedream/props-description)
  Reason: Some action params are missing descriptions