Merge pull request #306 from javierbrea/release

Release v3.3.0
javierbrea · Aug 19, 2023 · 6ea864b · 6ea864b
2 parents 16b2a01 + 23281ca
commit 6ea864b
Show file tree

Hide file tree

Showing 49 changed files with 6,698 additions and 2,132 deletions.
diff --git a/.eslintrc.js b/.eslintrc.js
@@ -0,0 +1,24 @@
+module.exports = {
+  env: {
+    node: true,
+    es6: true,
+  },
+  parserOptions: {
+    ecmaVersion: 2022,
+  },
+  plugins: ["prettier"],
+  rules: {
+    "prettier/prettier": [
+      "error",
+      {
+        printWidth: 99,
+        parser: "flow",
+      },
+    ],
+    "no-shadow": [2, { builtinGlobals: true, hoist: "all" }],
+    "no-undef": "error",
+    "no-unused-vars": ["error", { vars: "all", args: "after-used", ignoreRestSiblings: false }],
+  },
+  extends: ["prettier"],
+  root: true,
+};
diff --git a/.eslintrc.json b/.eslintrc.json
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
@@ -6,12 +6,15 @@ on:
       - release
       - pre-release
   pull_request:
+concurrency:  
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
 jobs:
   test:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        node: ["14.16.1", "15.14.0", "16.13.0", "17.0.1", "18.2.0"]
+        node: ["16.14.0", "18.2.0", "20.5.1"]
     steps:
       - name: Checkout
         uses: actions/checkout@v3
@@ -44,10 +47,10 @@ jobs:
           path: coverage
           retention-days: 1
   test-windows:
-    runs-on: windows-2019
+    runs-on: windows-2022
     strategy:
       matrix:
-        node: ["14.16.1", "15.14.0", "16.13.0", "17.0.1", "18.2.0"]
+        node: ["16.14.0", "18.2.0", "20.5.1"]
     steps:
       - name: Checkout
         uses: actions/checkout@v3
@@ -83,7 +86,7 @@ jobs:
       - name: Download test results
         uses: actions/download-artifact@v3
         with:
-          name: coverage-16.13.0
+          name: coverage-18.2.0
           path: coverage
       - name: Coveralls
         uses: coverallsapp/github-action@master

diff --git a/.github/workflows/check-package-version.yml b/.github/workflows/check-package-version.yml
@@ -3,6 +3,9 @@ on:
   pull_request:
     branches:
       - master
+concurrency:  
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
 jobs:
   check-package-version:
     runs-on: ubuntu-latest

diff --git a/.github/workflows/publish-to-github.yml b/.github/workflows/publish-to-github.yml
@@ -10,7 +10,7 @@ jobs:
     # Setup .npmrc file to publish to GitHub Packages
     - uses: actions/setup-node@v3
       with:
-        node-version: '16.x'
+        node-version: '18.x'
         registry-url: 'https://npm.pkg.github.com'
         # Defaults to the user or organization that owns the workflow file
         scope: '@javierbrea'

diff --git a/.github/workflows/publish-to-npm.yml b/.github/workflows/publish-to-npm.yml
@@ -9,7 +9,7 @@ jobs:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
-        node-version: '16.x'
+        node-version: '18.x'
         registry-url: 'https://registry.npmjs.org/'
     - run: npm ci
     - run: npm publish

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -10,6 +10,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/).
 ### Fixed
 ### Removed
 
+## [3.3.0] - 2023-08-19
+
+### Added
+- feat(#298): Add `importKind` option to `element-types`, `entry-point` and `external` rules. It allows to define if the rule applies when the dependency is being imported as a value or as a type.
+- chore: Add meta name and version to plugin exported object
+- chore: Handle concurrency in pipelines
+
+### Fixed
+- fix(#295): Replace template values in custom messages using a Regexp, so it replaces all occurrences
+- fix: Do not throw error when rule contains matchers for captured values but element has not captured values
+
+### Changed
+- chore(deps): Update dependencies
+- chore(deps): Use NodeJs 16.x, 18.x and 20.x in pipelines
+- refactor: Use optional chain expressions
+
 ## [3.2.0] - 2023-07-30
 
 ### Changed

diff --git a/README.md b/README.md
@@ -261,7 +261,7 @@ Some rules require extra configuration, and it has to be defined in each specifi
 
 The docs of each rule contains an specification of their own options, but __the main rules share the format in which the options have to be defined__. The format described here is valid for options of [`element-types`](docs/rules/element-types.md), [`external`](docs/rules/external.md) and [`entry-point`](docs/rules/entry-point.md) rules.
 
-Options set an `allow` or `disallow` value by default, and provide an array of rules. Each matching rule will override the default value and the value returned by previous matching rules. So, the final result of the options, once processed for each case, will be `allow` or `disallow`, and this value will be applied by the plugin rule in the correspondant way, making it to produce an eslint error or not.
+Options set an `allow` or `disallow` value by default, and provide an array of rules. Each matching rule will override the default value and the value returned by previous matching rules. So, the final result of the options, once processed for each case, will be `allow` or `disallow`, and this value will be applied by the plugin rule in the correspondent way, making it to produce an eslint error or not.
 
 ```jsonc
 {
@@ -277,6 +277,8 @@ Options set an `allow` or `disallow` value by default, and provide an array of r
           "from": ["helpers"],
           // ...disallow importing this type of elements
           "disallow": ["modules", "components"],
+          // ..for this kind of imports (applies only when using TypeScript)
+          "importKind": "value",
           // ...and return this custom error message
           "message": "Helpers must not import other thing than helpers"
         },
@@ -300,6 +302,7 @@ Remember that:
 
 * __`from/target`__: `<element matchers>` Depending of the rule to which the options are for, the rule will be applied only if the file being analyzed matches with this element matcher (`from`), or the dependency being imported matches with this element matcher (`target`).
 * __`disallow/allow`__: `<value matchers>` If the plugin rule target matches with this, then the result of the rule will be "disallow/allow". Each rule will require a type of value here depending of what it is checking. In the case of the `element-types` rule, for example, another `<element matcher>` has to be provided in order to check the type of the local dependency.
+* __`importKind`__: `<string>` _Optional_. It is useful only when using TypeScript, as it allows to define if the rule applies when the dependency is being imported as a value or as a type. It can be also defined as an array of strings, or a micromatch pattern. Note that possible values to match with are `"value"`, `"type"` or `"typeof"`. For example, you could define that "components" can import "helpers" as a value, but not as a type. So, `import { helper } from "helpers/helper-a"` would be allowed, but `import type { Helper } from "helpers/helper-a"` would be disallowed.
 * __`message`__: `<string>` Optional. If the rule results in an error, the plugin will return this message instead of the default one. Read [error messages](#error-messages) for further info.
 
 > Tip: Properties `from/target` and `disallow/allow` can receive a single matcher, or an array of matchers.
@@ -340,6 +343,7 @@ Available properties in error templates both from `file` or `dependency` are:
 * `internalPath`: File path being analyzed or imported. Relative to the element's root path.
 * `source`: Available only for `dependency`. The source of the `import` statement as it is in the code.
 * `parent`: If the element is child of another element, it is also available in this property, which contains correspondent `type`, `internalPath` and captured properties as well.
+* `importKind`: Available only for `dependency` when using TypeScript. It contains the kind of import being analyzed. Possible values are `"value"`, `"type"` or `"typeof"`.
 * ...All captured properties are also available
 
 > Tip: Read ["Global settings"](#global-settings) for further info about how to capture values from elements.

diff --git a/docs/rules/element-types.md b/docs/rules/element-types.md
@@ -19,13 +19,14 @@ It checks `import` statements between the element types of the project based on
   * `from`: `<element matchers>` If the file being analyzed matches with this, then the rule will be executed to know if it allows/disallows the `import`. If not, the rule is skipped.
   * `disallow`: `<element matchers>` If the element being imported matches with this, then the result of the rule will be "disallow", and the import will be notified as an `eslint` error (this value can be overwritten by a next rule returning "allow")
   * `allow`: `<element matchers>` If the element being imported matches with this, then the result of the rule will be "allow", and the import will not be notified as an `eslint` error (this value can be overwritten by a next rule returning "disallow")
+  * `importKind`: `<string>` Optional. It is useful only when using TypeScript, as it allows to define if the rule applies when the dependency is being imported as a value or as a type. It can be also defined as an array of strings, or a micromatch pattern. Note that possible values to match with are `"value"`, `"type"` or `"typeof"`.
   * `message`: `<string>` Custom error message only for this rule. Read ["error messages"](#error-messages) for further info.
 
 ##### Comparing captures of the file element with captures of the imported element
 
 As a bonus of this rule, the `<capturedValuesObject>` option of the "element matchers" in the `allow`/`disallow` properties supports replacements with the captured values of the `from` element. It sounds complicated, but it can be easy to understand with an example:
 
-Suposse you want that helpers of one category can only import helpers of the same category. Then, you need to compare the value of the `category` captured in `from` with the value of the `category` captured in `allow`. You can use the special pattern `${capturedKey}` in the `allow` options, and it will be replaced by the correspondant captured key in `from` before using `micromatch` to check if the value matches.
+Suppose you want that helpers of one category can only import helpers of the same category. Then, you need to compare the value of the `category` captured in `from` with the value of the `category` captured in `allow`. You can use the special pattern `${capturedKey}` in the `allow` options, and it will be replaced by the correspondent captured key in `from` before using `micromatch` to check if the value matches.
 
 So, if the `from` element has captured values `{ family: "atom", elementName: "component-a" }`, then the next element matcher in the `allow` property: `["helpers", { "category": "!${family}-${elementName}" }]` will only match if the helper captured category has a value matching `"!atom-component-a"` _(which may has not sense at all, but is useful to illustrate how the replacement works. An example with a more useful usage of this feature can be seen in the next options example)_
 
@@ -44,7 +45,9 @@ So, if the `from` element has captured values `{ family: "atom", elementName: "c
             // from helper elements
             "from": ["helpers"],
             // allow importing helper elements
-            "allow": ["helpers"]
+            "allow": ["helpers"],
+            // allow only importing value, not type. Useful only in TypeScript
+            "importKind": "value"
           },
           {
             // from component elements
@@ -154,6 +157,13 @@ _Helpers can't import components:_
 import AtomA from 'components/atoms/atom-a'
 ```
 
+_Helpers can't import type from helpers:_
+
+```js
+// src/helpers/permissions/roles.js
+import type { SomeParser } from 'helpers/data/parse'
+```
+
 _Helpers can't import modules:_
 
 ```js
@@ -237,10 +247,11 @@ import ModuleB from 'modules/module-b'
 
 This rule provides a lot of information about the specific option producing an error, so the user can have enough context to solve it.
 
-* If the error is produced because all imports are disallowed by default, and no rule is specificly allowing it, then the message provides information about the file and the dependency types and captured values: `No rule allowing this dependency was found. File is of type 'components' with category 'molecules' and elementName 'molecule-c'. Dependency is of type 'modules' with domain 'domain-a' and elementName 'module-a'`.
+* If the error is produced because all imports are disallowed by default, and no rule is specifically allowing it, then the message provides information about the file and the dependency types and captured values: `No rule allowing this dependency was found. File is of type 'components' with category 'molecules' and elementName 'molecule-c'. Dependency is of type 'modules' with domain 'domain-a' and elementName 'module-a'`.
 * If the error is produced by a specific option, then the message includes information about the option producing it: `Importing elements of type 'components' with category 'atoms' and elementName '*-a' is not allowed in elements of type 'helpers' with elementName 'helper-c'. Disallowed in rule 1`
+* If the rule contains an `importKind` property, then the message also includes information about the import kind: `Importing kind "value" from elements of type 'components' with category 'atoms' and elementName '*-a' as 'value' is not allowed in elements of type 'helpers' with elementName 'helper-c'. Disallowed in rule 1`
 
-You can also configure a custom error message for changing this default behaviour, or even custom error messages only for a specific rule option. Read ["error messages"](../../README.md#error-messages) in the main docs for further info about how to configure messages.
+You can also configure a custom error message for changing this default behavior, or even custom error messages only for a specific rule option. Read ["error messages"](../../README.md#error-messages) in the main docs for further info about how to configure messages.
 
 ## Further reading
 

diff --git a/docs/rules/entry-point.md b/docs/rules/entry-point.md
@@ -19,6 +19,7 @@ It checks `import` statements to the elements of the project and ensure that eac
   * `target`: `<element matchers>` If the element being imported matches with this, then the rule will be executed to know if it allows/disallows the `import`. If not, the rule is skipped.
   * `disallow`: `<string>` A [`micromatch` pattern](https://github.com/micromatch/micromatch). If the element being imported matches with this, then the result of the rule will be "disallow", and the import will be notified as an `eslint` error (this value can be overwritten by a next rule returning "allow")
   * `allow`: `<string>` A [`micromatch` pattern](https://github.com/micromatch/micromatch). If the element being imported matches with this, then the result of the rule will be "allow", and the import will not be notified as an `eslint` error (this value can be overwritten by a next rule returning "disallow")
+  * `importKind`: `<string>` Optional. It is useful only when using TypeScript, as it allows to define if the rule applies when the dependency is being imported as a value or as a type. It can be also defined as an array of strings, or a micromatch pattern. Note that possible values to match with are `"value"`, `"type"` or `"typeof"`.
   * `message`: `<string>` Custom error message only for this rule. Read ["error messages"](#error-messages) for further info.
 
 ##### Options example
@@ -40,7 +41,9 @@ It checks `import` statements to the elements of the project and ensure that eac
             // when importing components or modules
             "target": ["components", "modules"],
             // only allow index.js
-            "allow": "index.js"
+            "allow": "index.js",
+            // allow only importing values, not types. Useful only in TypeScript
+            "importKind": "value"
           }
         ]
       }
@@ -134,6 +137,14 @@ import ModuleB from 'modules/module-b/ModuleB'
 
 ```
 
+_type from index.js from modules can't be imported:_
+
+```js
+// src/modules/module-a/ModuleA.js
+import type ModuleB from 'modules/module-b'
+
+```
+
 ### Examples of **correct** code for this rule:
 
 _Helper file can be imported:_
@@ -174,6 +185,7 @@ This rule provides a lot of information about the specific option producing an e
 
 * If the error is produced because all entry points are disallowed by default, and no rule is specificly allowing it, then the message provides information about the dependency type and captured values: `No rule allows the entry point 'fooFile.js' in dependencies of type 'components' with category 'molecules' and elementName 'molecule-c'`.
 * If the error is produced by a specific option, then the message includes information about the option producing it: `The entry point 'fooFile.js' is not allowed in elements of type 'helpers' with elementName 'helper-c'. Disallowed in rule 2`
+* If the rule contains an `importKind` property, then the message also includes information about the import kind: `The entry point 'fooFile.js' is not allowed in elements of type 'helpers' with elementName 'helper-c' when importing type. Disallowed in rule 2`
 
 You can also configure a custom error message for changing this default behaviour, or even custom error messages only for a specific rule option. Read ["error messages"](../../README.md#error-messages) in the main docs for further info about how to configure messages.