Content
View differences
Updated by Bruno Pagno 3 days ago
As a developer working on BlockNote extensions
I want a seamless development experience
**Acceptance Criteria**
* BlockNote extensions is moved to the main OpenProject repository
* Code + Tests stay separate
* We still want to be able to release independently (?), but should have automatic releases with OpenProject to ensure the versions always match
* tbd: How will we handle translations? Should they stay in their own Crowdin project?
* Could it cause trouble when both Crowdin projects need to access the same repository?
* The way it is now is confusing and it would be better to merge the translations when both projects are in the same repository anyway
* The old repository mentions its new domicile in the README
* The old repository is archived
\-----
**Pro**
* We don't need to make changes in two repositories if the way how op-blocknote-extensions is set up, changes
* Probably easier to understand setup / build steps for new developers
* We could use pull previews to show something to Parimal or Wieland before merging it
* Changes to the API which affect BNE would (hopefully / more likely) surface as failing tests (we only have smoke tests in OpenProject for BNE)
**Contra**
* Git history is less nice with content from all other OpenProject development in there
* It's harder to keep op-blocknote-extensions "separate" code wise (for integration with 3rd party applications)
* Version & release management should still be independent, which will be strange
\-----
Passion week thoughts
**Goals**
* [x] move op-blocknote-extensions inside openproject core repo keeping the git history
* [x] publish to NPM with a custom GH action
* [ ] introduce a changelog
* [x] ci for linting and testing
* [x] [ ] Handle crowdin translations
**Even more goals**
* developer experience for local dev
* symlink when in dev
* can this under be a watcher process?
* on release build with the npm published version
* ci that tests agains the local version, instead of the NPM published version
* ideally this only runs, when op-blocknote-extensions is changed, and maybe only a subset of all rails specs
* make pull-preview possible with the local op-blocknote-extensions version instead the npm one
<br>
I want a seamless development experience
**Acceptance Criteria**
* BlockNote extensions is moved to the main OpenProject repository
* Code + Tests stay separate
* We still want to be able to release independently (?), but should have automatic releases with OpenProject to ensure the versions always match
* tbd: How will we handle translations? Should they stay in their own Crowdin project?
* Could it cause trouble when both Crowdin projects need to access the same repository?
* The way it is now is confusing and it would be better to merge the translations when both projects are in the same repository anyway
* The old repository mentions its new domicile in the README
* The old repository is archived
\-----
**Pro**
* We don't need to make changes in two repositories if the way how op-blocknote-extensions is set up, changes
* Probably easier to understand setup / build steps for new developers
* We could use pull previews to show something to Parimal or Wieland before merging it
* Changes to the API which affect BNE would (hopefully / more likely) surface as failing tests (we only have smoke tests in OpenProject for BNE)
**Contra**
* Git history is less nice with content from all other OpenProject development in there
* It's harder to keep op-blocknote-extensions "separate" code wise (for integration with 3rd party applications)
* Version & release management should still be independent, which will be strange
\-----
Passion week thoughts
**Goals**
* [x] move op-blocknote-extensions inside openproject core repo keeping the git history
* [x] publish to NPM with a custom GH action
* [ ] introduce a changelog
* [x] ci for linting and testing
* [x]
**Even more goals**
* developer experience for local dev
* symlink when in dev
* can this under be a watcher process?
* on release build with the npm published version
* ci that tests agains the local version, instead of the NPM published version
* ideally this only runs, when op-blocknote-extensions is changed, and maybe only a subset of all rails specs
* make pull-preview possible with the local op-blocknote-extensions version instead the npm one
<br>