feat!: fix example, buncheefication, cleanup #603
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
I was hoping to keep these changes separate, but ran into some issues with using the new packages in examples that necessitated some build changes. 1) I've updated the `file-upload` example to use the new packages. I ran into a weird build issue trying to do this - something about `Authenticator` not being exported from the UMD builds? - and did some research into how other projects I like are built, which lead me to `bunchee`, the tool SWR uses for builds (https://github.com/vercel/swr/blob/main/package.json#L94), is probably our best bet... 2) I love `bunchee` so far - it's much simpler and seems to do "the right things" when building TS into libraries suitable for use in a variety of modern JS environments. You can read more about bunchee here: https://github.com/huozhi/bunchee I've used `bunchee` to pull the build step into each of the packages separately, which should make it easier and more efficient to work on a single package in isolation. Because `bunchee` doesn't need a bunch of manual config, this was possible with a minimum of boilerplate and setup. 3) I've removed the old packages and a bunch of configs and docs that point to them. This made (2) easier, since I could just make a wholesale switch rather than trying to keep some stuff working with the old rollup builds and other stuff working with `bunchee`. 4) Tests are still failing: the `vitest` issue I ran into a couple weeks ago reared its head again and this seems like the right time to upgrade `vitest` rather than leaving it pinned, but something about the `vitest` environment @yusefnapora put together last year doesn't play nice with the new `vitest` - I'll fix that before I mark this ready for review.
Two big changes: 1) use `happy-dom` environment rather than `js-dom` or our custom environment. A new, strange incompatibility between the crypto API `@noble/ed25519` expects and what `webcrypto` provides seems to be a problem after upgrading `vitest`, ie: ``` RUN v1.0.1 /Users/travis/dev/pl/w3ui/packages/core ❯ test/client.spec.ts (2) × createClient × createSpace ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 2 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ FAIL test/client.spec.ts > createClient FAIL test/client.spec.ts > createSpace TypeError: Failed to execute 'digest' on 'SubtleCrypto': 2nd argument is not instance of ArrayBuffer, Buffer, TypedArray, or DataView. ❯ Object.sha512 ../../node_modules/.pnpm/@noble[email protected]/node_modules/@noble/ed25519/lib/esm/index.js:860:52 ❯ getExtendedPublicKey ../../node_modules/.pnpm/@noble[email protected]/node_modules/@noble/ed25519/lib/esm/index.js:674:39 ❯ Module.getPublicKey ../../node_modules/.pnpm/@noble[email protected]/node_modules/@noble/ed25519/lib/esm/index.js:680:19 ❯ derive ../../node_modules/.pnpm/@[email protected]/node_modules/@ucanto/principal/src/ed25519/signer.js:42:35 ❯ generate ../../node_modules/.pnpm/@[email protected]/node_modules/@ucanto/principal/src/ed25519/signer.js:28:31 ❯ Module.create ../../node_modules/.pnpm/@web3-storage[email protected]/node_modules/@web3-storage/w3up-client/src/index.node.js:38:49 ``` This seems to go away entirely when using `happy-dom`, which means we can also get rid of our custom vitest environment. Win! 2) Stop using `@testing-library/react-hooks` - it looks like I missed the fact that it's been deprecated! https://github.com/testing-library/react-hooks-testing-library/tree/main#a-note-about-react-18-support The new API in `@testing-library/react` is just a little different, so I've updated the tests accordingly.
I've disabled linting in the example repo, but want to re-enable it once I've taken a pass at upgrading the linting in this project in general
travis
changed the title
I've disabled the ones that don't exist anymore, but am going to go back and reimplement them next
this will help keep other examples less duplicative, and demonstrates how our components can be used to build a design-system-specific component library
|
We'll probably want some kind of followup task to this to unpublish the npm packages we no longer plan to maintain? Otherwise probably people will stumble upon them via search results, try to use them, and be frustrated that they are no longer supported. |
|
@travis should this probably be |
gobengo
approved these changes
Dec 8, 2023
travis
changed the title
we generally don't want to clear our pnpm-lock.yaml unless something really weird happens, and most build artifacts go in `dist` now
something about one of the new deps was giving this branch heartburn, so rebuild it by checking out from `dee82b6` and running `pnpm install`
This was referenced Dec 11, 2023
travis
pushed a commit
that referenced
this pull request
Dec 11, 2023
🤖 I have created a release *beep* *boop* --- ## [2.0.0](core-v1.1.1...core-v2.0.0) (2023-12-11) ### ⚠ BREAKING CHANGES * fix example, buncheefication, cleanup ([#603](#603)) ### Features * fix example, buncheefication, cleanup ([#603](#603)) ([4a1c660](4a1c660)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
travis
added a commit
that referenced
this pull request
Dec 11, 2023
🤖 I have created a release *beep* *boop* --- ## [2.0.0](react-v1.3.0...react-v2.0.0) (2023-12-11) ### ⚠ BREAKING CHANGES * fix example, buncheefication, cleanup ([#603](#603)) ### Features * fix example, buncheefication, cleanup ([#603](#603)) ([4a1c660](4a1c660)) ### Bug Fixes * unpin core version ([#611](#611)) ([69a8241](69a8241)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Travis Vachon <[email protected]>
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.
I was hoping to keep these changes separate, but ran into some issues with using the new packages in examples that necessitated some build changes.
I've updated the
file-uploadexample to use the new packages. I ran into a weird build issue trying to do this - something aboutAuthenticatornot being exported from the UMD builds? - and did some research into how other projects I like are built, which lead me to believe thatbunchee, the tool SWR uses for builds (https://github.com/vercel/swr/blob/main/package.json#L94), is probably our best bet...I love
buncheeso far - it's much simpler and seems to do "the right things" when building TS into libraries suitable for use in a variety of modern JS environments. You can read more about bunchee here:https://github.com/huozhi/bunchee
I've used
buncheeto pull the build step into each of the packages separately, which should make it easier and more efficient to work on a single package in isolation. Becausebuncheedoesn't need a bunch of manual config, this was possible with a minimum of boilerplate and setup.bunchee.