@shopify/shopify-api 6.0.0-rc7 → 6.0.0-rc9

package/CONTRIBUTING.md

@@ -1,39 +0,0 @@
-# Contributing
-
-We welcome your contributions to the project. There are a few steps to take when looking to make a contribution.
-
-- Open an issue to discuss the feature/bug
-- If feature/bug is deemed valid then fork repo.
-- Implement patch to resolve issue.
-- Include tests to prevent regressions and validate the patch.
-- Update the docs for any API changes.
-- Submit a pull request.
-
-# Bug Reporting
-
-Shopify API Library for Node uses GitHub issue tracking to manage bugs, please open an issue there.
-
-# Feature Request
-
-You can open a new issue on the GitHub issues and describe the feature you would like to see.
-
-# Developing the library
-
-Requirements:
-
-- [Node](https://nodejs.org/en/) v14 or above
-- [Yarn](https://yarnpkg.com/) v1.22 or above
-
-You can set up your development environment by running the following:
-
-```
-git clone git@github.com:Shopify/shopify-api-node.git # get the code
-cd shopify-node-api                                   # change into the source directory
-yarn install                                          # install dependencies
-yarn build                                            # build library
-```
-
-Helpful commands
-
-- `yarn lint` will run linting to make sure your code is of high standard
-- `yarn test` will run testing to ensure your code is covered by test cases

package/RELEASING.md

@@ -1,77 +0,0 @@
-# Releasing shopify-node-api
-
-1. Check the Semantic Versioning page for info on how to version the new release: [http://semver.org](http://semver.org)
-
-1. Ensure your local repo is up-to-date
-
-   ```shell
-   git checkout main && git pull
-   ```
-
-1. Add an entry for the new release to `CHANGELOG.md`, and/or move the contents from the _Unreleased_ to the new release
-
-1. Increment the version in `lib/version.ts`.
-
-1. Stage the `CHANGELOG.md` and `lib/version.ts` files
-
-   ```shell
-   git add CHANGELOG.md lib/version.ts
-   ```
-
-1. The following command updates the version (in `package.json`), creates the appropriate tag, commits all staged changes and pushes to the remote repository
-
-   ```shell
-   yarn version [ --patch | --minor | --major ]
-   ```
-
-   Select the applicable option to the `yarn version` command to increment the corresponding part of the version number, i.e., for a version of `x.y.z`,
-
-   - `--patch` to increment the `z`
-   - `--minor` to increment the `y`
-   - `--major` to increment the `x`
-
-   The `preversion` and `postversion` scripts in `package.json` take care of the pre (testing) and post (pushing) actions.
-
-1. Login to `shipit` and press _Deploy_ on the appropriate commit (the commit description will be the version number).
-
-## Release Candidates
-
-For significant API changes that could result in significant refactoring on the part of developers, consider releasing a few _Release Candidate_ versions in advance of the final version. `shipit` is configured to do this from the `shopify_api_next` branch.
-
-1. Ensure your local repo is up-to-date
-
-   ```shell
-   git checkout shopify_api_next && git pull
-   ```
-
-1. (optional) Add an entry for the release candidate to `CHANGELOG.md`
-
-1. Increment the version in `lib/version.ts`, ensuring that it ends with `-rcN`, where `N` starts at `1` and increments with each Release Candidate.
-
-1. Update the version in `package.json` to match that in `lib/version.ts`
-
-1. Stage the `CHANGELOG.md`, `lib/version.ts`, and `package.json` files
-
-   ```shell
-   git add CHANGELOG.md lib/version.ts package.json
-   ```
-
-1. Commit the files to the repo
-
-   ```shell
-   git commit -m "Packaging for release vX.Y.Z-rcN"
-   ```
-
-1. Tag the commit with an _annotated_ tag (required for the `--follow-tags` of the `push` command). Note that it's very important that the tag includes `-rc` as part of the tag name - this is how `shipit` will recognize that it's a release candidate, not a general release.
-
-   ```shell
-   git tag -a vX.Y.Z-rcN -m "Release candidate N of version X.Y.Z"
-   ```
-
-1. Push the files to the remote repository, along with the annotated tag.
-
-   ```shell
-   git push origin shopify_api_next --follow-tags
-   ```
-
-1. Login to `shipit`, search for the _next_ environment for `shopify-api-node`, and press _Deploy_ on the appropriate commit (the commit description will be the version number).

package/adapters/__e2etests__/.env.test

@@ -1 +0,0 @@
-HTTP_SERVER_PORT=9999

package/docs/issues.md

@@ -1,25 +0,0 @@
-# Known issues and caveats
-
-By following this guide, you will have a fully functional Shopify app. However, there are some things you should be aware of before using your new app in a production environment.
-
-## Notes on session handling
-
-Before you start writing your application, please note that the Shopify library stores some information in sessions, like the API access token and the approved scopes.
-
-Browsers are making it increasingly more difficult to use 3rd party cookies (e.g. [Firefox](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#tracking_protection)), and because embedded apps run in an iframe, their cookies are considered 3rd party cookies. **That means that this library cannot rely on cookies for sessions**, which is what web frameworks typically use for session management.
-
-This library can use your app's data storage to store sessions to work around that issue, using `SessionStorage`.
-Each app may choose a different storage strategy, so the library cannot assume any specific strategy will be available, but [we provide some options](../session-storage/README.md) to help you quickly set up your app.
-
-- By default, Node.js apps will use `SQLiteSessionStorage`, which will enable you to start developing your app by storing sessions using the file-based SQLite package.
-  - It will use a file named `database.sqlite` by default.
-  - It's designed to be a single-process solution and _may_ be sufficient for your production needs depending on your application's design and needs.
-- For runtimes that don't support file-system access, we also provide `MemorySessionStorage`.
-  - This strategy is **purposely** designed to be a single-process, development-only solution. It **will leak** memory in most cases and delete all sessions when your app restarts. You should **never** use it in production apps.
-  - We don't default to this strategy for CloudFlare workers, because it only works if you're running all your endpoints on the same worker, which won't always happen.
-
-The other storage adapters cover a variety of production-grade storage options, but require further setup from the app to provide database access.
-
-If you wish to have an alternative storage solution, you must use a `CustomSessionStorage` solution in your production app- you can reference our [usage example with redis](usage/customsessions.md) to get started.
-
-[Back to guide index](../README.md)