Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Preconstruct to manage monorepo #285

Merged
merged 7 commits into from
Nov 30, 2021
Merged

Use Preconstruct to manage monorepo #285

merged 7 commits into from
Nov 30, 2021

Conversation

anttimaki
Copy link
Contributor

@anttimaki anttimaki commented Nov 29, 2021

This PR intends to do the same things as PR #37. I initially started to work with it, rebasing it to current master etc., but I encountered one error after another and finally decided to start from the scratch.

Basically I followed this tutorial and fixed any problems I detected. Some of them were already solved in the earlier PR, so the solutions look somewhat similar.

Closes #37

https://monorepo.guide/getting-started suggests that apps directory
should contain "user-facing apps and websites" and packages directory
should contain "packages designed to be consumed by other packages
(published OR internal)". I'm not sure if this is a common convention,
but it lookes simple and clear enough for me.

Rename our nextjs app to @thunderstore/nextjs and components package
to @thunderstore/components. Fix imports to reflect the changes.

Update the references in GitHub Actions files to reflect the new file
paths.
Basically the changes done here are the results of following this
tutorial: https://monorepo.guide/getting-started . Additionally some
changes are from an earlier pr (#37), which was also about setting up
Preconstruct.

* Add Preconstruct as dependency
* Setup Babel and ESLint
* Rename workspaces to use the structure used in the tutorial. I don't
  know if this is some convention oslt, but it seems like a nice, clear
  structure for the repo
* Add a script for using Preconstruct, and a postinstall hook to run it
  automatically while devving (see root package.json)
* Move all devDependencies to dependencies on root package.json. This
  was recommended by Preconstruct, but I can't quite recall why
Update the action to read all versions from dependencies, since the
root package.json no longer contains a devDependencies section. Update
the packages in the action to use the same versions that are used in
the actual repo, and then update the Docker image to use the same Node
version.
Introducing Preconstruct caused some weird issues. Whenever
"react-markdown" or "remark-gfm" is imported in a normal way, the app
crashes with "Error: Element type is invalid: expected a string (for
built-in components) or a class/function (for composite components) but
got: undefined". Furthermore, the error only occurs after a full page
refresh - regular imports don't cause problems when changes are updated
by live-reload.

The same error occurs with the package versions used before this PR as
well as with the latest ones.
As far as I can tell, the recommendation is that each app and package
in the monorepo defines all the dependencies it uses. Yarn workspaces
will then handle hoisting and deduplicating the dependencies. Root
level package.json should contain the tooling dependencies used by the
project as a whole. Also I believe this only matters in cases where
packages are going to be published separately. I didn't manage to find
any solid information on this.
Copy link
Member

@MythicManiac MythicManiac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, nice work 👍

Should mention merging this closes #37 (in the PR description) so that indeed happens when this is merged.

@anttimaki anttimaki merged commit 37ede8c into master Nov 30, 2021
@anttimaki anttimaki deleted the preconstruct-rework branch November 30, 2021 06:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants