fix(load): add support for factory-callback parser presets#834
fix(load): add support for factory-callback parser presets#834
Conversation
| name: config.parserPreset, | ||
| path: resolvedParserPreset, | ||
| parserOpts: resolvedParserConfig.parserOpts | ||
| parserOpts: require(resolvedParserPreset) |
There was a problem hiding this comment.
The code before the first attempt was (await require(resolvedParserPreset)).parserOpts, which is not going to work with the newer callback-presets. I took a look at @commitlint/resolve-extended and it does exactly the same as written here, I think that's a better way-to-go compared to the instant-extraction of parserOpts (like the code I just mentioned).
| typeof parser.parserOpts === 'object' && | ||
| typeof parser.parserOpts.parserOpts === 'object' | ||
| ) { | ||
| return parser.parserOpts.parserOpts; |
There was a problem hiding this comment.
I'm not sure how this "happens", but I think it's related to the context-overwrite when calling @commitlint/resolve-extended. The failing test was the parser-preset-override, I don't think anything is wrong with that tests though.
What I think what happens:
commitlint.config.jsoverwritesparserPresetwith a module- overwrite is picked up and module is loaded
- due to this change, it's not using
parserOptsbut the parser preset itself.
| 'fixtures/recursive-parser-preset-conventional-atom' | ||
| ); | ||
| // the package file is nested in 2 folders, `npm.bootstrap` cant do that | ||
| await execa('npm', ['install'], { |
There was a problem hiding this comment.
If there is any other way, let me know 😄 I think this is not that bad, but I didn't see any other option for now.
marionebl
force-pushed
the
refactor/load-preset
branch
from
d32a641 to
c705cd4
Compare
2 participants
Description
Fixes #830
Motivation and Context
Not all presets worked flawlessly with the existing load-preset code. The code had no support for presets that required a initialise-callback. I'm not sure if the "example atom preset" from here worked because of this. But this PR helps solving that issue.
We could also integrate the
conventional-changelog-loaderinto@commitlint/load, didn't have much luck with that but I could try implementing it again. I do have some doubt if it will remove some of the code already added in this PR, because we still have to initialise it.Usage examplesHow Has This Been Tested?
Instead of creating similar-structured presets, I added the actual preset modules in the tests. So far, I could find 3 different types of presets.
{ parserOpts: {} }, like angular(null, { parserOpts: {} }), like atomparserOptsas function), like conventionalcommitsAll these changelogs are now feature-tested and included in the PR.
Types of changes
Checklist: