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

replace react-scripts with vite #1314

Closed
eventualbuddha opened this issue Dec 13, 2021 · 2 comments
Closed

replace react-scripts with vite #1314

eventualbuddha opened this issue Dec 13, 2021 · 2 comments
Assignees

Comments

@eventualbuddha
Copy link
Collaborator

eventualbuddha commented Dec 13, 2021

Why?

  • It's fast. Vite (pronounced "veet") uses esbuild, which is potentially orders of magnitude faster than with babel + webpack. Add TypeScript type checking on top of that and the difference is even more huge.
  • It's lightweight. CRA includes the kitchen sink and battery-includes everything. This is good for getting started, but bad for upgrades and customization. Vite includes only what you need for HMR development and fast builds. Testing/linting is separate.

The Plan

Proposal
I'd like to evaluate it for use with vxsuite. I've done some initial exploration and it seems doable, but will require some restructuring. For example:

eventualbuddha added a commit that referenced this issue Dec 13, 2021
Rather than relying on the NodeJS `assert` module or a polyfill in the browser, we can use this simple `assert` function to achieve the same effect. This removes one of the roadblocks toward using a non-webpack dev/build system.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 13, 2021
Transforms uses of `assert` that can be converted automatically to use `@votingworks/utils` instead.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 13, 2021
Transforms uses of `assert` that can be converted automatically to use `@votingworks/utils` instead.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 13, 2021
Transforms uses of `assert` that can be converted automatically to use `@votingworks/utils` instead.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 14, 2021
This was done by the codemod from #1316.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 14, 2021
eventualbuddha added a commit that referenced this issue Dec 14, 2021
Our `assert` doesn't have helpers like `equal`, so just pass a truthy value. Also, fix issues flagged by linting.

Refs #1314
eventualbuddha added a commit that referenced this issue Dec 14, 2021
eventualbuddha added a commit that referenced this issue Dec 14, 2021
Our `assert` doesn't have helpers like `equal`, so just pass a truthy value. Also, fix issues flagged by linting.

Refs #1314
@eventualbuddha
Copy link
Collaborator Author

#1669 was related to this work.

eventualbuddha added a commit that referenced this issue Apr 5, 2022
Refs #1314

In several packages we import the `crypto` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to explicit polyfills from npm.

In all but the `lsd` module (because it's NodeJS-only), replaces uses of `crypto` with `randombytes` (which uses `crypto` in NodeJS and `globalThis.crypto` in the browser) or `js-sha256` (which likewise uses `crypto` in NodeJS and its own implementation in the browser).
eventualbuddha added a commit that referenced this issue Apr 5, 2022
Refs #1314

In several packages we import the `assert` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to our own `assert` from `@votingworks/utils`.
eventualbuddha added a commit that referenced this issue Apr 5, 2022
As we move toward #1314, this will make it harder to introduce a dependency on the built-in NodeJS packages.
eventualbuddha added a commit that referenced this issue Apr 6, 2022
Refs #1314

In several packages we import the `crypto` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to explicit polyfills from npm.

In all but the `lsd` module (because it's NodeJS-only), replaces uses of `crypto` with `randombytes` (which uses `crypto` in NodeJS and `globalThis.crypto` in the browser) or `js-sha256` (which likewise uses `crypto` in NodeJS and its own implementation in the browser).
eventualbuddha added a commit that referenced this issue Apr 6, 2022
Refs #1314

In several packages we import the `assert` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to our own `assert` from `@votingworks/utils`.
eventualbuddha added a commit that referenced this issue Apr 6, 2022
As we move toward #1314, this will make it harder to introduce a dependency on the built-in NodeJS packages.
eventualbuddha added a commit that referenced this issue Apr 26, 2022
Refs #1314

In several packages we import the `crypto` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to explicit polyfills from npm.

In all but the `lsd` module (because it's NodeJS-only), replaces uses of `crypto` with `randombytes` (which uses `crypto` in NodeJS and `globalThis.crypto` in the browser) or `js-sha256` (which likewise uses `crypto` in NodeJS and its own implementation in the browser).
eventualbuddha added a commit that referenced this issue Apr 26, 2022
Refs #1314

In several packages we import the `assert` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to our own `assert` from `@votingworks/utils`.
eventualbuddha added a commit that referenced this issue Apr 26, 2022
As we move toward #1314, this will make it harder to introduce a dependency on the built-in NodeJS packages.
eventualbuddha added a commit that referenced this issue Apr 28, 2022
Refs #1314

In several packages we import the `crypto` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to explicit polyfills from npm.

In all but the `lsd` module (because it's NodeJS-only), replaces uses of `crypto` with `randombytes` (which uses `crypto` in NodeJS and `globalThis.crypto` in the browser) or `js-sha256` (which likewise uses `crypto` in NodeJS and its own implementation in the browser).
eventualbuddha added a commit that referenced this issue Apr 28, 2022
Refs #1314

In several packages we import the `assert` NodeJS built-in library. This works as expected in NodeJS, but for the browser we rely on CRA via webpack to bundle a polyfill. To reduce our reliance on CRA and webpack, this commit switches to our own `assert` from `@votingworks/utils`.
eventualbuddha added a commit that referenced this issue Apr 28, 2022
As we move toward #1314, this will make it harder to introduce a dependency on the built-in NodeJS packages.
eventualbuddha added a commit that referenced this issue May 17, 2022
Importing from a sub-path of a package doesn't play well with some tooling, especially when those packages are build-less as when using vite.

Refs #1314
eventualbuddha added a commit that referenced this issue May 17, 2022
Importing from a sub-path of a package doesn't play well with some tooling, especially when those packages are build-less as when using vite.

Refs #1314
eventualbuddha added a commit that referenced this issue May 17, 2022
Importing from a sub-path of a package doesn't play well with some tooling, especially when those packages are build-less as when using vite.

Refs #1314
eventualbuddha added a commit that referenced this issue May 17, 2022
Importing from a sub-path of a package doesn't play well with some tooling, especially when those packages are build-less as when using vite.

Refs #1314
eventualbuddha added a commit that referenced this issue May 24, 2022
Refs #1314

Switching to a buildless system will mean that TypeScript will see deeper into monorepo dependencies like `/ui` and their `@types/react` dependencies. This means we want the versions to match to avoid incompatibilities when e.g. type checking `bmd` or another frontend.
eventualbuddha added a commit that referenced this issue May 25, 2022
Refs #1314

We don't use service workers and probably never will. We don't need the types provided by `react-scripts`.
eventualbuddha added a commit that referenced this issue May 25, 2022
Refs #1314

We don't use service workers and probably never will. We don't need the types provided by `react-scripts`.
eventualbuddha added a commit that referenced this issue May 25, 2022
Refs #1314

We don't use service workers and probably never will. We don't need the types provided by `react-scripts`.
@eventualbuddha eventualbuddha changed the title test using Vite for dev+build instead of CRA replace react-scripts with vite Jun 9, 2022
eventualbuddha added a commit that referenced this issue Jun 24, 2022
eventualbuddha added a commit that referenced this issue Jun 24, 2022
eventualbuddha added a commit that referenced this issue Jun 24, 2022
eventualbuddha added a commit that referenced this issue Jun 24, 2022
@eventualbuddha
Copy link
Collaborator Author

I'm going to count this as done. We no longer use react-scripts, but we do still have some of the leftovers from ejecting. We can clean that stuff up later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants