proper builds + use pnpm workspaces #396
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
+ update root tasks
This was referenced Feb 1, 2023
Merged
|
Nice 1. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this PR adds proper builds to each package. So far, the source files were packaged as is (ES Modules / ESM), resulting in problems for CommonJS (CJS) based bundlers, see #381
With this PR, each package has a
buildtask, which builds eachindex.mjsasdist/index.mjs(ESM) +dist/index.js(CJS).In the process, I refactored the monorepo from npm workspaces to pnpm workspaces. This change was necessary to ensure a smooth package resolution.
I'll try to explain: To tell a bundler which file is the entry file, the
package.jsonhas the fieldsmain(CJS) andmodule(ESM), see explanation, also this stackoverflow.The problem: The
mainfield is also used by the dev server to resolve packages, see bare module import.Because of that, using the unbuilt
index.mjsasmainallows the dev server to instantly (hot) reload on change (it already does that), without the need to rebuild the whole package. Also, the tests can run without needing to build in advance.If the
mainwould contain the built CJS version, each package would need an additionalwatchtask that checks for file changes and reruns the build. This is potentially possible with workspace watching, but slows down development + further complicates the setup. Also, the build needs to run before testing to make sure themainfiles are there (adding builds to git is not a nice option).The rescue comes with pnpm and its ability to overwrite
mainandmoduleon publish, using thepublishConfigfield, see pnpm docs. Although npm also supportspublishConfig, it does not support settingmain/module, see npm docs. pnpm has additional features that simplify working with monorepos. For example, I was able to find some wrong dependencies, which npm did not tell me about + pnpm is much faster. The only downside is that pnpm requires an additional install vianpm i pnpm -g+ using npm won't work.I have already tested the publishing, releasing 0.6.x versions: https://www.npmjs.com/search?q=%40strudel.cycles
Finally, using the strudel packages should be possible in all common scenarios, e.g. using codesandbox.
Also, I've started to update the core examples, the rest will follow.