Currently when I lint in huge project, like [station](https://github.com/superfaceai/station), I get verbose, yet useless output (see eg. [here](https://github.com/superfaceai/station/runs/6325585597?check_suite_focus=true)): When there is an error with my files, at the end I get only this unhelpful message: ``` Detected 1 problem › Error: ❌ Errors were found ``` And I need to scroll back and search through the list of linted files to find my error. My suggestion here is for CLI is to act like any sensitive linter / test harness out there, and display summary of errors at the end. Alternatively `lint` command could also display only errors instead of listing all the validated files, having a verbose switch to also display OK files – still, a summary of errors at the end would be nice nevertheless.
Last active 7 months ago
Today I have updated Superface from 1.1.0 to the latest and got an error that `super.json` could not be found. Looking at the path, it has reverted back to the default one, despite the fact that I have set env var for `SUPERFACE_PATH` to properly find the settings. After testing multiple versions, this seems to be something that has crept up in 1.4. ## Expected Behavior Superface init should respect custom path to `super.json`. ## Current Behavior When setting custom path: ```js process.env.SUPERFACE_PATH = 'assets/app/superface/super.json' ``` I get the following error on startup: ```bash W20220525-16:44:13.668(2)? (STDERR) /home/storyteller/.meteor/packages/meteor-tool/.126.96.36.199gbfmsj.1hck++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280 W20220525-16:44:13.681(2)? (STDERR) throw(ex); W20220525-16:44:13.681(2)? (STDERR) ^ W20220525-16:44:13.681(2)? (STDERR) W20220525-16:44:13.681(2)? (STDERR) Unable to find super.json W20220525-16:44:13.682(2)? (STDERR) W20220525-16:44:13.682(2)? (STDERR) super.json not found in "/home/storyteller/Web/Literary-Universe/app/.meteor/local/build/programs/server/superface/super.json" W20220525-16:44:13.682(2)? (STDERR) Error: ENOENT: no such file or directory, stat '/home/storyteller/Web/Literary-Universe/app/.meteor/local/build/programs/server/superface/super.json' ``` ## Possible Solution I think this has to do with this part: https://github.com/superfaceai/one-sdk-js/blob/a948565c000188612d787a71cc2401650273934a/src/internal/superjson/superjson.ts#L51 Which combines the default path, but there is no way it is getting `SUPERFACE_PATH`. ## Steps to Reproduce Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include code to reproduce, if relevant 1. Put `super.json` in another location 2. Set `SUPERFACE_PATH` env var to point to that location 3. Initialize SuperfaceClient 4. You should get an error ## Your Environment Include as many relevant details about the environment you experienced the bug in. Preferably include: * Version used: 1.4.1, works fine in 1.3.0 * Environment name and version (e.g. Node 8): Meteor. 2.7.2 * Operating System and version: Ubuntu 22.04
Last active 7 months ago
Currently both of our transactional profiles provide map for the `mailchimp` provider, which is confusing for users unfamiliar with Mailchimp's offering. I just got from a support call with user who tried to use the Mailchimp map with Mailchimp's API key and was getting `Invalid key` error. The solution was to navigate to Transactional Email in Mailchimp's Dashboard and enter Mandrillapp dashboard. Apparently the original intent behind the `mailchimp` provider was to respect that it's a single company and product. However, this seems to be confusing and could even turn problematic with other, Mailchimp-specific map. My suggestion here is to introduce a new `mandrillapp` provider and change existing maps for Mailchimp to use that provider instead. Before we do that, make sure that Mailchimp's APIs require a different API key for sure.
Last active 8 months ago