Merge branch 'master' into bump-ci

Author: mtrezza

.babelrc

@@ -7,7 +7,8 @@
         ["@babel/preset-env", {
             "targets": {
                 "node": "12"
-            }
+            },
+            "exclude": ["proposal-dynamic-import"]
         }]
     ],
     "sourceMaps": "inline"

CHANGELOG.md

@@ -151,6 +151,7 @@ ___
 - Refactor: uniform issue templates across repos (Manuel Trezza) [#7528](https://github.com/parse-community/parse-server/pull/7528)
 - ci: bump ci environment (Manuel Trezza) [#7539](https://github.com/parse-community/parse-server/pull/7539)
 - CI now pushes docker images to Docker Hub (Corey Baker) [#7548](https://github.com/parse-community/parse-server/pull/7548)
+- Allow cloud string for ES modules (Daniel Blyth) [#7560](https://github.com/parse-community/parse-server/pull/7560)
 - docs: Introduce deprecation ID for reference in comments and online search (Manuel Trezza) [#7562](https://github.com/parse-community/parse-server/pull/7562)
 
 ## 4.10.3
@@ -178,15 +179,15 @@ ___
 
 *Versions >4.5.2 and <4.10.0 are skipped.*
 
-> ⚠️ A security incident caused a number of incorrect version tags to be pushed to the Parse Server repository. These version tags linked to a personal fork of a contributor who had write access to the repository. The code to which these tags linked has not been reviewed or approved by Parse Platform. Even though no releases were published with these incorrect versions, it was possible to define a Parse Server dependency that pointed to these version tags, for example if you defined this dependency: 
+> ⚠️ A security incident caused a number of incorrect version tags to be pushed to the Parse Server repository. These version tags linked to a personal fork of a contributor who had write access to the repository. The code to which these tags linked has not been reviewed or approved by Parse Platform. Even though no releases were published with these incorrect versions, it was possible to define a Parse Server dependency that pointed to these version tags, for example if you defined this dependency:
 > ```js
 > "parse-server": "[email protected]:parse-community/parse-server.git#4.9.3"
 > ```
-> 
+>
 > We have since deleted the incorrect version tags, but they may still show up if your personal fork on GitHub or locally. We do not know when these tags have been pushed to the Parse Server repository, but we first became aware of this issue on July 21, 2021. We are not aware of any malicious code or concerns related to privacy, security or legality (e.g. proprietary code). However, it has been reported that some functionality does not work as expected and the introduction of security vulnerabilities cannot be ruled out.
 >
-> You may be also affected if you used the Bitnami image for Parse Server. Bitnami picked up the incorrect version tag `4.9.3` and published a new Bitnami image for Parse Server. 
-> 
+> You may be also affected if you used the Bitnami image for Parse Server. Bitnami picked up the incorrect version tag `4.9.3` and published a new Bitnami image for Parse Server.
+>
 >**If you are using any of the affected versions, we urgently recommend to upgrade to version `4.10.0`.**
 
 ## 4.5.2

CONTRIBUTING.md

@@ -309,7 +309,11 @@ The _type_ is the category of change that is made, possible types are:
 - `ci` - continuous integration
 - `test` - tests
 
-The _summary_ is a short change description in present tense, not capitalized, without period at the end.
+The _summary_ is a short change description in present tense, not capitalized, without period at the end. This summary will also be used as the changelog entry.
+- It must be short and self-explanatory for a reader who does not see the details of the full pull request description
+- It must not contain abbreviations, e.g. instead of `LQ` write `LiveQuery`
+- It must use the correct product and feature names as referenced in the documentation, e.g. instead of `Cloud Validator` use `Cloud Function validation`
+- In case of a breaking change, the summary must not contain duplicate information that is also in the [BREAKING CHANGE](#breaking-change) chapter of the pull request description. It must not contain a note that it is a breaking change, as this will be automatically flagged as such if the pull request description contains the BREAKING CHANGE chapter.
 
 For example:
 
@@ -321,11 +325,15 @@ Currently, we are not making use of the commit _scope_, which would be written a
 
 ### Breaking Change
 
-If a pull request contains a braking change, the text of the pull request must contain the word `BREAKING CHANGE` capitalized as the _last, most bottom_ part of the text. It must be followed by an empty line, then a short description of the character of the breaking change, and ideally how the developer should address it.
+If a pull request contains a braking change, the description of the pull request must contain a special chapter at the bottom.
+
+The chapter consists of the phrase `BREAKING CHANGE`, capitalized, in a single line without any formatting. It must be followed by an empty line, then a short description of the breaking change, and ideally how the developer should address it. This chapter should contain more details focusing on the "breaking” aspect of the change, as it is intended to assist the developer in adapting their deployment. However, keep it concise, as it will also become part of the changelog entry.
 
 For example:
 
 ```
+Detailed pull request description...
+
 BREAKING CHANGE
 
 The door handle has be pulled up to open the door, not down. Adjust your habits accordingly by walking on your hands.

spec/CloudCode.spec.js

@@ -39,6 +39,14 @@ describe('Cloud Code', () => {
     });
   });
 
+  it('can load cloud code as a module', async () => {
+    process.env.npm_package_type = 'module';
+    await reconfigureServer({ cloud: './spec/cloud/cloudCodeModuleFile.js' });
+    const result = await Parse.Cloud.run('cloudCodeInFile');
+    expect(result).toEqual('It is possible to define cloud code in a file.');
+    delete process.env.npm_package_type;
+  });
+
   it('can create functions', done => {
     Parse.Cloud.define('hello', () => {
       return 'Hello world!';

spec/cloud/cloudCodeModuleFile.js

@@ -0,0 +1,3 @@
+Parse.Cloud.define('cloudCodeInFile', () => {
+  return 'It is possible to define cloud code in a file.';
+});

src/ParseServer.js

@@ -103,7 +103,11 @@ class ParseServer {
       if (typeof cloud === 'function') {
         cloud(Parse);
       } else if (typeof cloud === 'string') {
-        require(path.resolve(process.cwd(), cloud));
+        if (process.env.npm_package_type === 'module') {
+          import(path.resolve(process.cwd(), cloud));
+        } else {
+          require(path.resolve(process.cwd(), cloud));
+        }
       } else {
         throw "argument 'cloud' must either be a string or a function";
       }