Releases: commonalityco/commonality
@commonalityco/data-codeowners@0.2.39
Patch Changes
- a4a63fe: Fixes a bug where codeowner paths would not match a path to a package directory
commonality@0.2.50
commonality-checks-recommended@0.0.27
Patch Changes
- Updated dependencies [56baf27]
- commonality@0.2.50
@commonalityco/studio@0.2.47
Patch Changes
- 56baf27: Fixes an issue where package.json files with missing "name" properties would cause any command to throw an error. We now ignore these invalid packages and continue with the command while displaying an error.
@commonalityco/data-tags@0.2.43
Patch Changes
- Updated dependencies [56baf27]
- @commonalityco/data-project@0.2.42
@commonalityco/data-project@0.2.42
Patch Changes
- 56baf27: Fixes an issue where package.json files with missing "name" properties would cause any command to throw an error. We now ignore these invalid packages and continue with the command while displaying an error.
@commonalityco/data-packages@0.2.42
commonality@0.2.49
Patch Changes
- 98e83dc: Update names of exported static checks in the commonality-checks-recommended package
commonality@0.2.48
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/studio@0.2.46