- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 526
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
chore: use pnpm instead of npm #1567
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This is ready for review now @YousefED |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome!! looking forward to using this
- name: Soft release | ||
id: soft-release | ||
run: pnpx pkg-pr-new publish './packages/*' # --compact enable compact after release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool! when do you use it for testing?
@@ -0,0 +1,61 @@ | |||
# ./.github/workflows/publish.yml | |||
name: Publish |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome! very curious about this!
.npmrc
Outdated
@@ -0,0 +1,4 @@ | |||
link-workspace-packages=deep | |||
prefer-workspace-packages=true | |||
public-hoist-pattern[]=prosemirror-* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need this?
Also; maybe cleaner to use pnpm-workspace.yaml
(I could find the dashed options because the pnpm docs describe the yaml options which are camelCase :/ )
@@ -1,4 +1,4 @@ | |||
import glob from "fast-glob"; | |||
import { globSync } from "tinyglobby"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what was the reason for this? curious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to figure out why the gen step went from 2 seconds to 45 seconds. Turns out that we were globbing through node_modules that pnpm put in each directory.
I thought that the globbing library may have been an issue with the performance. So I switched out the package for a lighter weight one, but I then found it going through the node_modules and had no way of filtering so I had to rewrite it. So, I kept this lib
@@ -7,12 +7,21 @@ import { | |||
} from "@floating-ui/react"; | |||
import { useEffect, useMemo } from "react"; | |||
|
|||
type UIElementPosition = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm gessing a ts change or sth that made this necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, otherwise:
boolean,
YousefED1 day ago
I'm gessing a ts change or sth that made this necessary?
The inferred type of 'useUIElementPositioning' cannot be named without a reference to '.pnpm/@[email protected][email protected][email protected][email protected]/node_modules/@floating-ui/react-dom'. This is likely not portable. A type annotation is necessary.
Triggered because I regenerated the node_modules so it upgraded TS
@@ -14,4 +14,5 @@ | |||
<Relationship Id="FAKE-ID" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="" TargetMode="External"/> | |||
<Relationship Id="FAKE-ID" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://www.blocknotejs.org" TargetMode="External"/> | |||
<Relationship Id="FAKE-ID" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/e1037269513fbdc121e06bb1bc7cf37b9045c8fc.gif"/> | |||
<Relationship Id="FAKE-ID" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/fontTable" Target="fontTable.xml"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
triggered by an upgrade?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, upgrade of a patch version
@@ -65,7 +73,9 @@ | |||
"typescript": "^5.3.3", | |||
"vite": "^5.3.4", | |||
"vite-plugin-eslint": "^1.8.1", | |||
"vitest": "^2.0.3" | |||
"vitest": "^2.0.3", | |||
"react": "^19", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be ^18?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put 19 to test against that, but 19 is stable now so it shouldn't matter which
@@ -2,7 +2,11 @@ import { pdfBlockMappingForDefaultSchema } from "./blocks.js"; | |||
import { pdfInlineContentMappingForDefaultSchema } from "./inlinecontent.js"; | |||
import { pdfStyleMappingForDefaultSchema } from "./styles.js"; | |||
|
|||
export const pdfDefaultSchemaMappings = { | |||
export const pdfDefaultSchemaMappings: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird that this was needed, typescript issue?
- "examples/*/*" | ||
- "playground" | ||
- "docs" | ||
- "shared" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nperez0111 I'm not sure shared
should be part of the workspace.
The way it is now, shared contains some code (utility functions) that's shared by different packages (mainly, the exporters). However, it's not bundled in it's own package. Rather, the functions are just included in the consuming packages
a) should we remove it here?
b) I tried to remove it, but then got an error in one of the exporters (TS errors in toMatchBinaryFileSnapshot
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The workspace defines where to install packages from. By default, pnpm installs packages "scoped" i.e. a project can only resolve the packages that it declares.
So, shared
has dependency on image-meta
(imageUtil) & @types/node
(binarySnapshotUtil). So when you remove it from the workspace, it can no longer find those packages since they exist in the project they are used in, not in it's source path.
There are two ways to resolve this. Make shared
into a workspace package (leveraging it only as an project, not a package), or install it's deps like I did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, remove the shared project altogether & just keep the files into their respective projects, which I'm most partial to since it keeps things simple.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, remove the shared project altogether & just keep the files into their respective projects, which I'm most partial to since it keeps things simple.
I think for code duplication that's not ideal. I think specifically for test utilities we should actually move a lot more to the shared
package (test cases and utilities that are shared across packages) - unless you have a better solution for this.
There are two ways to resolve this. Make shared into a workspace package (leveraging it only as an project, not a package), or install it's deps like I did.
I'm not sure I understand the difference between the two. Currently it's a workspace package right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for code duplication that's not ideal. I think specifically for test utilities we should actually move a lot more to the shared package (test cases and utilities that are shared across packages) - unless you have a better solution for this.
I think test utilities should be in/reusing the existing test package:
Line 2 in 7df528c
"name": "@blocknote/tests", |
So, the only one that I think is valid to live here is the image util, and even then, I don't see why this can't be either duplicated or exported from @blocknote/core
(ideally their would actually be a @blocknote/core/exporter
sub package for this reason)
I'm not sure I understand the difference between the two. Currently it's a workspace package right?
Sorry, I could've explained that better. The difference is:
- workspace package:
@blocknote/shared
as a devDep to whatever uses it (so linking via pnpm workspaces) - tricking vite to resolve it like we are doing now:
BlockNote/packages/xl-docx-exporter/vite.config.ts
Lines 23 to 25 in 27494f6
? ({ "@shared": path.resolve(__dirname, "../../shared/"), } as Record<string, string>)
In either of these cases, you still need anything shared
depends to be installed to this directory (whether you consider it a package or not).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
For (1), wouldn't it require us to publish that package to npm? (if we use functions from it in non-testing code)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, you can set it up where @blocknote/shared
is declared as not "external" (i.e. vite/rollup should bundle it into the package that you are trying to build like docx-exporter). So, at build time the import would be resolved correctly within the repo & the consumer would not need (or even know about) that package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah makes sense. I suppose that's cleaner than what we currently have, because dependencies are better managed right?
Should we go for that approach? Also happy to discuss whether the package is needed at all - I think easier to go over that on a call
This PR introduces using pnpm instead of npm, pnpm is much better suited for:
It also completely replaces lerna in favor of NX (which lerna was already based on). This gives us one tool to:
This PR also renames several PNPM scripts, to be more standard. The goal should be for PNPM scripts to already have the most commonly used tasks that you might need within the repo. It should be possible to do everything you need from the root of the repo.