This was likely happening because the package versions in the top level
package.json and the eslint-config package.json were different. I've synced them
for now.
> On a longer time frame, the idea is not have such conflicting cases, and
remove mostly all the top level package.json dependencies and for the rest rely
on them solely being in the top level package.json and not duplicated in two
places.
- yarn classic workspaces already do what we need
- The main benefit of turbo, the cache, is already disabled on dev builds. On
production builds, turbo doesn't support `next build` (this is mentioned in
Vercel's docs).
- We're not using their remote cache
- Maybe there is a monorepo size when the yarn workspace approach gets
unwieldly, but I feel we're not near that point.
Will bring it back if it gets missed.
The flat config requires enabling a flag in the VS code plugin, it in not
enabled by default.
"eslint.experimental.useFlatConfig": true
This is an unnecessary expectation from all developers on the project, so we for
now live with the old format.
VSCode still gives an error
We had to set the type to module to get the `import` to work. Setting .mjs
didn't work (eslint didn't recognize the file). Setting the type to module
should be (based on my current understanding) not affect us negatively since we
are exporting a TypeScript library not a bundled one, and all the other source
files apart from this are intended to be `*.ts`.
Refs:
- https://jeremyrichardson.dev/blog/saga_of_learning_exports_property_in_packagejson
- https://github.com/eslint/eslint/discussions/17021
This was because with 13.5 I was getting an error coming from emotion:
Unhandled Runtime Error
Error: Component selectors can only be used in conjunction with
@emotion/babel-plugin, the swc Emotion plugin, or another Emotion-aware compiler
transform.
Call Stack
- handleInterpolation
../node_modules/@emotion/serialize/dist/emotion-serialize.browser.esm.js (84:0)
- serializeStyles
../node_modules/@emotion/serialize/dist/emotion-serialize.browser.esm.js (264:0)
This is to prevent Next from forcefully overwriting the "moduleResolution" in
tsconfig.json to "node". If it is "node", then VS code cannot find the imports
we do from @repo/ui.
This was a bug in Next which was fixed in this PR:
https://github.com/vercel/next.js/pull/51957
To upgrade, I used:
yarn upgrade next@^13.5
The latest Next.js is 14, but I left it at the last release in the 13
series. Will deal with the upgrade to 14 later in a different PR.
The version field is still required, but we can additionally add a private for
both semantic signalling and preventing this from being published to npm.
