prepare next release#275
Conversation
- do not create a IncrementalChecker instance on the test thread - use worker-rpc so the tests can actually access the checker instance run by the service - fix include path in "tsconfig-imports.json" so the "should resolve *.vue in the same way as TypeScript" test actually compiles files - add two counter checks to make sure the compiler actually throws errors it finds at all
actually use the correct `useTypescriptIncrementalApi` value for some of the linter tests that were using the default value before
fix a bug where, as `tslint` was set to true and the files being checked had no parent folder with a tslint.json, tslint in these tests never found any warnings also fixes a failing test because a syntactic error was counted as linter warning
# [1.2.0-beta.3](https://github.com/Realytics/fork-ts-checker-webpack-plugin/compare/[email protected]@beta) (2019-04-22) ### Bug Fixes * **tests:** rework vue integration tests ([5ad2568](5ad2568))
when the options `checkSyntacticErrors: false` and `useTypescriptIncrementalApi: true` both were active, no semantic errors were emitted as soon as the first syntactic error was encountered this patches the `typescript` import to override that behavior see discussion in #257
improve generation of diagnostics, fix linter tests
# [1.2.0-beta.4](https://github.com/Realytics/fork-ts-checker-webpack-plugin/compare/[email protected]@beta) (2019-04-23) ### Bug Fixes * **tests:** fix linter tests that were doing nothing ([d078278](d078278)) * **tests:** linter tests - useTypescriptIncrementalApi usage ([e0020d6](e0020d6)) ### Features * **apiincrementalchecker:** improve generation of diagnostics ([ae80e5f](ae80e5f)), closes [#257](#257)
Add documentation on how to use hooks on a compiler instance.
Explain the purpose of arguments passed to plugin hooks.
docs: 📖 add hooks documentation
|
So we'd need to make a new release for the changes from #274 to land in the README. Also this lands a few test improvements and Since the |
|
I will take a look today’s evening :) |
|
I've resolved conflicts in the |
# [1.3.0-beta.1](https://github.com/Realytics/fork-ts-checker-webpack-plugin/compare/v1.2.0...v1.3.0-beta.1@beta) (2019-04-30) ### Bug Fixes * **tests:** fix linter tests that were doing nothing ([d078278](d078278)) * **tests:** linter tests - useTypescriptIncrementalApi usage ([e0020d6](e0020d6)) * **tests:** rework vue integration tests ([5ad2568](5ad2568)) ### Features * **apiincrementalchecker:** improve generation of diagnostics ([ae80e5f](ae80e5f)), closes [#257](#257)
|
Great! Who wants to pull the trigger? 😄 |
johnnyreilly
left a comment
johnnyreilly
left a comment
There was a problem hiding this comment.
First time with the semantic release hotness!
|
It looks like we can't merge as Travis isn't running or something... @piotr-oles can you investigate please? |
|
We have all these problems because not all commits were merged into beta :) Travis didn't want to build because when we merged master to beta, semantic-release created new release and updated CHANGELOG.md with |
|
Cool - is there a way we can avoid this happening in future? I'm keen we have a release process that just works™️ 😊 Is this happening just because this will be our first release end to end with semantic release? So in future these issues won't present? I'm a little confused / concerned with the problems we've been facing getting semantic release bedded in. Hopefully we can get past this and into a good release flow 🤞 |
swashata
left a comment
swashata
left a comment
There was a problem hiding this comment.
I have found a typo in the docs. Please accept the changes in this PR too :)
|
The most problematic is generation of the |
Co-Authored-By: piotr-oles <[email protected]>
|
My take away from that is that semantic release doesn't have a good workflow with regards to changelogs. That's super disappointing. I'm rather hesitant about us creating our own automation around this as that may end up being another thing to maintain as semantic release evolves. If there's not a good out of the box experience that we can have I'm inclined to say "well nevermind - let's just have the GitHub releases instead" It means we have to be online to see them and if we were ever to move the plugin elsewhere we'd need to recreate manually. Neither of those is a deal-breaker in my eyes. I value a simple release workflow above other concerns. If you want to drop the changelog generation I'm fine with that. 😊 |
|
Since the CHANGELOG is automatically generated from commit messages, I think we won't lose any metadata when dropping the automatic generation - even if this project were to move away from github some day in the future. The commit history won't be lost. |
|
I've created PR to drop |
|
The last thing we should remember is to use "Rebase and merge" when merging from the |
|
Good catch - thanks! |
Not everyone uses emoji in commits - so it's better to remove them than having two styles of commits
|
🎉 This PR is included in version 1.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
How did you get it to work? Can you just not rebase on a phone? |
|
Nope, looks like this was one last normal merge. I guess we'll have to rebase that one back to beta one last time and then we'll be golden as long as we don't push to master. |
5 participants
No description provided.