Releases: commonalityco/commonality
@commonalityco/data-tags@0.2.42
Patch Changes
-
65ee18a: This release addresses some common feedback around checks and initial setup.
We are moving from a TS/JS configuration file to a JSON file (
.commonality/config.json). It's common for developers to create custom checks during initial setup and the.commonalitydirectory, will now act as a folder to organize these checks before moving them into a package.{ "checks": { "*": [ "has-client-eslint-config", "recommended/sorted-dependencies", "@scope/team/custom-check" ] } }How checks are resolved in the JSON format:
- Checks can be configured with a path to a local file, relative to the
.commonalityfolder. Given a pathhas-foo, Commonality will first look for a file named "has-foo" within the.commonalityfolder. You can also pass a relative path like./testing/has-fooortesting/has-footo organize checks within the.commonalityfolder. - Checks can be configured via import path. Given a path
@scope/team/custom-check, Commonality will look for a default export from an entry point namedcustom-checkin the package named@scope/team. This logic follows the same convention asimport.meta.resolve. - Checks can be configured via a shortened import path. Given a path
test/has-foo, if there is no file located at.commonality/test/has-foo.tsthen it will look for a package namedcommonality-checks-testwith an entry point namedhas-foo. This allows for a standard convention and a more readable configuration file similar to eslint.
Previously the
messageproperty for a check object allowed a function that could be used to dynamically create an error message. There ended up being a lot of duplicated logic between themessageandvalidatefunction and in some cases the two could become out of sync for certain cases. This change change themessageproperty to only expect a string, ensuring that the happy path message will always be shown when runningcheck --verbose. To create a dynamic message, simply return a message object from thevalidatefunction. Now, Commonality will return afailorwarnstatus for any check who'svalidatefunction returns a value other thantrue.We now automatically create an id for each check on file resolution so the name property is no longer required to parallelize check functions.
- Checks can be configured with a path to a local file, relative to the
-
Updated dependencies [65ee18a]
- @commonalityco/data-project@0.2.41
- @commonalityco/utils-core@0.2.39
@commonalityco/data-project@0.2.41
Patch Changes
-
65ee18a: This release addresses some common feedback around checks and initial setup.
We are moving from a TS/JS configuration file to a JSON file (
.commonality/config.json). It's common for developers to create custom checks during initial setup and the.commonalitydirectory, will now act as a folder to organize these checks before moving them into a package.{ "checks": { "*": [ "has-client-eslint-config", "recommended/sorted-dependencies", "@scope/team/custom-check" ] } }How checks are resolved in the JSON format:
- Checks can be configured with a path to a local file, relative to the
.commonalityfolder. Given a pathhas-foo, Commonality will first look for a file named "has-foo" within the.commonalityfolder. You can also pass a relative path like./testing/has-fooortesting/has-footo organize checks within the.commonalityfolder. - Checks can be configured via import path. Given a path
@scope/team/custom-check, Commonality will look for a default export from an entry point namedcustom-checkin the package named@scope/team. This logic follows the same convention asimport.meta.resolve. - Checks can be configured via a shortened import path. Given a path
test/has-foo, if there is no file located at.commonality/test/has-foo.tsthen it will look for a package namedcommonality-checks-testwith an entry point namedhas-foo. This allows for a standard convention and a more readable configuration file similar to eslint.
Previously the
messageproperty for a check object allowed a function that could be used to dynamically create an error message. There ended up being a lot of duplicated logic between themessageandvalidatefunction and in some cases the two could become out of sync for certain cases. This change change themessageproperty to only expect a string, ensuring that the happy path message will always be shown when runningcheck --verbose. To create a dynamic message, simply return a message object from thevalidatefunction. Now, Commonality will return afailorwarnstatus for any check who'svalidatefunction returns a value other thantrue.We now automatically create an id for each check on file resolution so the name property is no longer required to parallelize check functions.
- Checks can be configured with a path to a local file, relative to the
-
Updated dependencies [65ee18a]
- @commonalityco/utils-core@0.2.39
@commonalityco/data-packages@0.2.41
Patch Changes
-
65ee18a: This release addresses some common feedback around checks and initial setup.
We are moving from a TS/JS configuration file to a JSON file (
.commonality/config.json). It's common for developers to create custom checks during initial setup and the.commonalitydirectory, will now act as a folder to organize these checks before moving them into a package.{ "checks": { "*": [ "has-client-eslint-config", "recommended/sorted-dependencies", "@scope/team/custom-check" ] } }How checks are resolved in the JSON format:
- Checks can be configured with a path to a local file, relative to the
.commonalityfolder. Given a pathhas-foo, Commonality will first look for a file named "has-foo" within the.commonalityfolder. You can also pass a relative path like./testing/has-fooortesting/has-footo organize checks within the.commonalityfolder. - Checks can be configured via import path. Given a path
@scope/team/custom-check, Commonality will look for a default export from an entry point namedcustom-checkin the package named@scope/team. This logic follows the same convention asimport.meta.resolve. - Checks can be configured via a shortened import path. Given a path
test/has-foo, if there is no file located at.commonality/test/has-foo.tsthen it will look for a package namedcommonality-checks-testwith an entry point namedhas-foo. This allows for a standard convention and a more readable configuration file similar to eslint.
Previously the
messageproperty for a check object allowed a function that could be used to dynamically create an error message. There ended up being a lot of duplicated logic between themessageandvalidatefunction and in some cases the two could become out of sync for certain cases. This change change themessageproperty to only expect a string, ensuring that the happy path message will always be shown when runningcheck --verbose. To create a dynamic message, simply return a message object from thevalidatefunction. Now, Commonality will return afailorwarnstatus for any check who'svalidatefunction returns a value other thantrue.We now automatically create an id for each check on file resolution so the name property is no longer required to parallelize check functions.
- Checks can be configured with a path to a local file, relative to the
-
Updated dependencies [65ee18a]
- @commonalityco/data-project@0.2.41
- @commonalityco/utils-core@0.2.39
@commonalityco/data-constraints@0.2.39
Patch Changes
-
65ee18a: This release addresses some common feedback around checks and initial setup.
We are moving from a TS/JS configuration file to a JSON file (
.commonality/config.json). It's common for developers to create custom checks during initial setup and the.commonalitydirectory, will now act as a folder to organize these checks before moving them into a package.{ "checks": { "*": [ "has-client-eslint-config", "recommended/sorted-dependencies", "@scope/team/custom-check" ] } }How checks are resolved in the JSON format:
- Checks can be configured with a path to a local file, relative to the
.commonalityfolder. Given a pathhas-foo, Commonality will first look for a file named "has-foo" within the.commonalityfolder. You can also pass a relative path like./testing/has-fooortesting/has-footo organize checks within the.commonalityfolder. - Checks can be configured via import path. Given a path
@scope/team/custom-check, Commonality will look for a default export from an entry point namedcustom-checkin the package named@scope/team. This logic follows the same convention asimport.meta.resolve. - Checks can be configured via a shortened import path. Given a path
test/has-foo, if there is no file located at.commonality/test/has-foo.tsthen it will look for a package namedcommonality-checks-testwith an entry point namedhas-foo. This allows for a standard convention and a more readable configuration file similar to eslint.
Previously the
messageproperty for a check object allowed a function that could be used to dynamically create an error message. There ended up being a lot of duplicated logic between themessageandvalidatefunction and in some cases the two could become out of sync for certain cases. This change change themessageproperty to only expect a string, ensuring that the happy path message will always be shown when runningcheck --verbose. To create a dynamic message, simply return a message object from thevalidatefunction. Now, Commonality will return afailorwarnstatus for any check who'svalidatefunction returns a value other thantrue.We now automatically create an id for each check on file resolution so the name property is no longer required to parallelize check functions.
- Checks can be configured with a path to a local file, relative to the
@commonalityco/data-codeowners@0.2.38
Patch Changes
-
65ee18a: This release addresses some common feedback around checks and initial setup.
We are moving from a TS/JS configuration file to a JSON file (
.commonality/config.json). It's common for developers to create custom checks during initial setup and the.commonalitydirectory, will now act as a folder to organize these checks before moving them into a package.{ "checks": { "*": [ "has-client-eslint-config", "recommended/sorted-dependencies", "@scope/team/custom-check" ] } }How checks are resolved in the JSON format:
- Checks can be configured with a path to a local file, relative to the
.commonalityfolder. Given a pathhas-foo, Commonality will first look for a file named "has-foo" within the.commonalityfolder. You can also pass a relative path like./testing/has-fooortesting/ 10000 has-footo organize checks within the.commonalityfolder. - Checks can be configured via import path. Given a path
@scope/team/custom-check, Commonality will look for a default export from an entry point namedcustom-checkin the package named@scope/team. This logic follows the same convention asimport.meta.resolve. - Checks can be configured via a shortened import path. Given a path
test/has-foo, if there is no file located at.commonality/test/has-foo.tsthen it will look for a package namedcommonality-checks-testwith an entry point namedhas-foo. This allows for a standard convention and a more readable configuration file similar to eslint.
Previously the
messageproperty for a check object allowed a function that could be used to dynamically create an error message. There ended up being a lot of duplicated logic between themessageandvalidatefunction and in some cases the two could become out of sync for certain cases. This change change themessageproperty to only expect a string, ensuring that the happy path message will always be shown when runningcheck --verbose. To create a dynamic message, simply return a message object from thevalidatefunction. Now, Commonality will return afailorwarnstatus for any check who'svalidatefunction returns a value other thantrue.We now automatically create an id for each check on file resolution so the name property is no longer required to parallelize check functions.
- Checks can be configured with a path to a local file, relative to the
commonality@0.2.47
Patch Changes
- 0508b8f: Adds a
workspacesproperty to the project configuration file. This will allow you to override your package manager's workspaces. This will also allow integrated monorepos to filter packages without adding a workspaces property to their package manager.
commonality-checks-recommended@0.0.24
Patch Changes
- Updated dependencies [0508b8f]
- commonality@0.2.47
@commonalityco/utils-core@0.2.38
Patch Changes
- 0508b8f: Adds a
workspacesproperty to the project configuration file. This will allow you to override your package manager's workspaces. This will also allow integrated monorepos to filter packages without adding a workspaces property to their package manager.
@commonalityco/ui-graph@0.2.41
Patch Changes
- Updated dependencies [0508b8f]
- @commonalityco/utils-core@0.2.38
@commonalityco/ui-constraints@0.2.42
Patch Changes
- @commonalityco/ui-core@0.2.39
- @commonalityco/ui-graph@0.2.41