#7165 externalize datadir (#8645) (#8664)

.github/workflows/tests.yml

@@ -53,7 +53,7 @@ jobs:
         run: npm run lint
 
       - name: Doc build
-        run: npm run doc
+        run: npm run jsdoc:build
 
       - name: Check i18n
         run: npm run i18n
@@ -141,7 +141,7 @@ jobs:
         run: npm install
 
       - name: compile
-        run: npm run compile
+        run: npm run fe:build
       ################
       # JAVA CHECKS
       ##############

CONTRIBUTING.md

@@ -1,5 +1,4 @@
-Contributing to MapStore 
-==========================
+# Contributing to MapStore
 
  1. [Getting Involved](#getting-involved)
  2. [Reporting Bugs](#reporting-bugs)
@@ -11,6 +10,7 @@ Contributing to MapStore
 There are several ways you can contribute to MapStore development.
 If you are a developer, you can provide new features and bug fixes, by using pull requests.
 But you can also help by:
+
 - discovering and [reporting bugs](#reporting-bugs);
 - improving [documentation](#improving-documentation);
 - helping others on the [MapStore users mailing list](https://groups.google.com/d/forum/mapstore-users) or [MapStore developers mailing list](https://groups.google.com/d/forum/mapstore-developers)
@@ -27,12 +27,12 @@ and if it's already reported, just add any additional details in the comments.
 After you've made sure that you've found a new MapStore bug,
 here are some tips for creating a helpful report that will make fixing it much easier and quicker:
 
- * Write a **descriptive, specific title**. Bad: *Map does not show*. Good: *Doing X in IE9 causes Z*.
- * Include **browser, OS and MapStore version** info in the description.
- * Create a **simple test case** that demonstrates the bug (e.g. using [JSFiddle](http://jsfiddle.net/) or [JS Bin](http://jsbin.com/)).
- * Check whether the bug can be reproduced in **other browsers**.
- * Check if the bug occurs in the stable version, master, or both.
- * *Bonus tip:* if the bug only appears in the master version but the stable version is fine,
+- Write a **descriptive, specific title**. Bad: *Map does not show*. Good: *Doing X in Chrome causes Z*.
+- Include **browser, OS and MapStore version** info in the description.
+- Create a **simple test case** that demonstrates the bug (e.g. using [JSFiddle](http://jsfiddle.net/) or [JS Bin](http://jsbin.com/)).
+- Check whether the bug can be reproduced in **other browsers**.
+- Check if the bug occurs in the stable version, master, or both.
+- *Bonus tip:* if the bug only appears in the master version but the stable version is fine,
    use `git bisect` to find the exact commit that introduced the bug.
 
 If you just want some help with your project,
@@ -71,28 +71,26 @@ Please do not commit to the `master` branch, or your unrelated changes will go i
 
 Your pull request must:
 
- * Follow MapStore's coding style.
+- Follow MapStore's coding style.
 
- * Pass the integration tests run automatically by the Github Action - Continuous
+- Pass the integration tests run automatically by the Github Action - Continuous
    Integration system.
 
- * Address a single issue or add a single item of functionality. (Start the pull request title with the addressed issues if in case and #NUMBER_OF_ISSUE)
+- Address a single issue or add a single item of functionality. (Start the pull request title with the addressed issues if in case and #NUMBER_OF_ISSUE)
 
- * Contain a clean history of small, incremental, logically separate commits,
+- Contain a clean history of small, incremental, logically separate commits,
    with no merge commits.
 
- * Use clear commit messages.
-
- * Be possible to merge automatically.
+- Use clear commit messages.
 
+- Be possible to merge automatically.
 
 ### The `test` and `lint` build targets
 
 It is strongly recommended that you run
 
-    $ npm test
-
-    $ npm run lint
+    npm test
+    npm run lint
 
 before every commit.  This will catch many problems quickly, and it is much
 faster than waiting for the CI integration tests to run.
@@ -101,15 +99,14 @@ The `test` build target runs a number of quick tests on your code.
 
 The `lint` build target runs ESLint checks on your code.
 
-
 ### File Naming Conventions
 
 The test files should in a folder named `__tests__` in the module folder.
 
 If you are testing a specific component follow the following convention:
 
-* Component: `MyComponent.jsx`
-* Test File: `MyComponent-test.jsx`
+- Component: `MyComponent.jsx`
+- Test File: `MyComponent-test.jsx`
 
 ### Follow MapStore's coding style
 
@@ -118,6 +115,7 @@ MapStore follows a strict coding style, enforced by [ESLint](http://eslint.org/)
 The set of used rules can be found in the ESLint config package[eslint-config-mapstore](https://github.com/geosolutions-it/MapStore2/blob/master/utility/eslint/index.js) file, deployed on npm and configured in the `package.json`.
 
 Additionally if you use VScode these are the extensions to install that will help notify lint errors on the fly
+
 - [error lens](https://marketplace.visualstudio.com/items?itemName=usernamehw.errorlens)
 - [ESlint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)
 
@@ -130,14 +128,14 @@ We suggest also to add the following configuration that will fix lint errors whi
 You can run the linter locally on your machine before committing using the `lint`
 target:
 
-    $ npm run lint
+    npm run lint
 
 In addition, take care of adding the standard file header in each javascript / css added file, and update copyright years in modified ones.
 
 This is the standard file header:
 
 ```javascript
-/*
+/**
  * Copyright <year>, GeoSolutions Sas.
  * All rights reserved.
  *
@@ -154,21 +152,19 @@ can be used to configure whitespace and charset handling in your editor.  See
 that file for a description of the conventions.  The [EditorConfig](
 http://editorconfig.org/#download) site links to plugins for various editors.
 
-### Pass the integration tests run automatically by the Travis CI system
+### Pass the integration tests run automatically by the CI system
 
 The integration tests contain a number of automated checks to ensure that the
 code follows the MapStore style and does not break tests or examples.  You
 can run the integration tests locally using the `test` target:
 
-    $ npm test
-
+    npm test
 
 ### Address a single issue or add a single item of functionality
 
 Please submit separate pull requests for separate issues.  This allows each to
 be reviewed on its own merits.
 
-
 ### Contain a clean history of small, incremental, logically separate commits, with no merge commits
 
 The commit history explains to the reviewer the series of modifications to the
@@ -185,12 +181,11 @@ history.
 and [Pro GIT](http://git-scm.com/book/en/Git-Tools-Rewriting-History) have
 explain how to use them.
 
-
 ### Use clear commit messages
 
 Commit messages should be short, begin with a verb in the imperative, and
 contain no trailing punctuation. We follow
-http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>
 for the formatting of commit messages.
 
 Git commit message should look like:
@@ -213,9 +208,9 @@ Please keep the header line short, no more than 50 characters.
 ### Be possible to merge automatically
 
 Occasionally other changes to `master` might mean that your pull request cannot
-be merged automatically. In this case you may need to merge your branch with 
+be merged automatically. In this case you may need to merge your branch with
 more recent `master`, resolve any conflicts, and `git push` to update
-your branch so that it can be merged automatically. 
+your branch so that it can be merged automatically.
 Please try to **not** rewrite the history of a pull request after the first review or it will be very hard for the reviewer to see if the required changes has been applied, expecially for big pull requests.
 
 ## Improving Documentation