Convert your Postman collections into different formats https://packagist.org/packages/axenov/pm-convert
Go to file
2023-09-18 00:33:37 +08:00
src Skip postman schema conversion if it is already same as specified (#10) 2023-09-18 00:33:37 +08:00
tests Conversion to 2.0 (--v2.0), improvements and fixes (#10) 2023-09-17 23:09:19 +08:00
.gitignore Refactorings 2023-09-10 09:03:54 +08:00
composer.json Initial and very naive conversion v2.0 => v2.1 (#10) 2023-09-17 23:59:37 +08:00
composer.lock Refactorings 2023-09-10 09:03:54 +08:00
LICENSE First basic ready-to-use implementation 2023-08-03 16:43:17 +08:00
phpunit.xml Refactorings 2023-09-10 09:03:54 +08:00
pm-convert Fixed error when -o is missied 2023-08-13 10:50:52 +08:00
README.md Introducing --var and some improvements in variables interpolation 2023-09-10 15:28:09 +08:00

Postman collection converter

Convert your Postman collections into different formats.

Very fast.
Offline.
Without 3rd-party dependencies.

These formats are supported for now: http, curl, wget.

This project was quickly written in my spare time to solve one exact problem in one NDA-project, so it may contain stupid errors and (for sure) doesn't cover all possible cases according to collection schema. So feel free to propose your improvements.

Supported features

  • collection schema v2.1;
  • Bearer auth;
  • replace vars in requests by stored in collection and environment file;
  • export one or several collections (or even whole directories) into one or all of formats supported at the same time;
  • all headers (including disabled for http-format);
  • json body (forces header Content-Type to application/json);
  • formdata body (including disabled fields for http-format; forces header Content-Type to multipart/form-data)

Planned features

  • conversion between postman schema v2.1 <-> v2.0 (#11);
  • support as many as possible/necessary of authentication kinds (currently only Bearer supported);
  • support as many as possible/necessary of body formats (currently only json and formdata);
  • documentation generation support (markdown) with responce examples (if present) (#6);
  • maybe some another convert formats (like httpie or something...);
  • better logging;
  • 90%+ test coverage, phpcs, psalm, etc.;
  • web version.

Install and upgrade

composer global r axenov/pm-convert   # install
composer global u axenov/pm-convert   # upgrade

Make sure your ~/.config/composer/vendor/bin is in $PATH env:

echo $PATH | grep --color=auto 'composer'
# if not then execute this command and add it into ~/.profile:
export PATH="$PATH:~/.config/composer/vendor/bin"

Usage

$ pm-convert --help
Postman collection converter
Usage:
        ./pm-convert -f|-d PATH -o OUTPUT_PATH [ARGUMENTS] [FORMATS]
        php pm-convert -f|-d PATH -o OUTPUT_PATH [ARGUMENTS] [FORMATS]
        composer pm-convert -f|-d PATH -o OUTPUT_PATH [ARGUMENTS] [FORMATS]
        ./vendor/bin/pm-convert -f|-d PATH -o OUTPUT_PATH [ARGUMENTS] [FORMATS]

Possible ARGUMENTS:
        -f, --file          - a PATH to a single collection file to convert from
        -d, --dir           - a PATH to a directory with collections to convert from
        -o, --output        - a directory OUTPUT_PATH to put results in
        -e, --env           - use environment file with variables to replace in requests
        --var "NAME=VALUE"  - force replace specified env variable called NAME with custom VALUE
                              (see interpolation notes below)
        -p, --preserve      - do not delete OUTPUT_PATH (if exists)
        -h, --help          - show this help message and exit
        -v, --version       - show version info and exit

If no ARGUMENTS passed then --help implied.
If both -f and -d are specified then only unique set of files from both arguments will be converted.
-f or -d are required to be specified at least once, but each may be specified multiple times.
PATH must be a valid path to readable json-file or directory.
OUTPUT_PATH must be a valid path to writeable directory.
If -o or -e was specified several times then only last one will be used.

Possible FORMATS:
        --http   - generate raw *.http files (default)
        --curl   - generate shell scripts with curl command
        --wget   - generate shell scripts with wget command

If no FORMATS specified then --http implied.
Any of FORMATS can be specified at the same time.

Notes about variable interpolation:
        1. You can use -e to tell where to find variables to replace in requests.
        2. You can use one or several --var to replace specific env variables to your own value.
        3. Correct syntax is `--var "NAME=VALUE". NAME may be in curly braces like {{NAME}}.
        4. Since -e is optional, a bunch of --var will emulate an environment. Also it does not
           matter if there is --var in environment file you provided or not.
        5. Even if you (not) provided -e and/or --var, any of variable may still be overridden
           from collection (if any), so last ones has top priority.

Example:
    ./pm-convert \ 
        -f ~/dir1/first.postman_collection.json \ 
        --directory ~/team \ 
        --file ~/dir2/second.postman_collection.json \ 
        --env ~/localhost.postman_environment.json \ 
        -d ~/personal \ 
        --var "myvar=some value" \ 
        -o ~/postman_export 

Notices

  1. Result of pm-convert execution is bunch of generated files. Most likely they will contain errors such as not interpolated {{variables}} values (due to missed ones in collection), wrong command format or GETs with bodies. You must review any generated file before using.
  2. Make sure every (I mean every) collection (not collection file), its folders and/or requests has unique names. If not, you can rename them in Postman or convert collections with similar names into different directories. Otherwise any generated file may be accidently overwritten by another one.

How to implement a new format

  1. Create new namespace in ./src/Converters and name it according to format of your choice
  2. Create two classes for converter and request object which extends Converters\Abstract\Abstract{Converter, Request} respectively
  3. Change constants values in your new request class according to format you want to implement
  4. Write your own logic in converter's __toString() method, write new methods and override abstract ones

License

You can use, share and develop this project according to MIT License.

Postman is protected legal trademark of Postman, Inc.


Disclaimer

I'm not affiliated with Postman, Inc. in any way.

I'm just a backend developer who is forced to use this javascripted gigachad-shitmonster.

So the goal of this project is to:

  • take the data and its synchronization under own transparent control;
  • easily migrate to something more RAM tolerant and productive, easier and free to use;
  • get off the needle of the vendor lock, strict restrictions for teams and not to pay incredible $ for heavy useless WYSIWYGs;
  • give YOU these opportunities.