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

chore: replace yarn with npm #629

Merged
merged 15 commits into from Aug 16, 2023
Merged

chore: replace yarn with npm #629

merged 15 commits into from Aug 16, 2023

Conversation

boneskull
Copy link
Contributor

This removes yarn in lieu of npm.

I'm unsure if this affects @lavamoat/yarn-plugin-allow-scripts or not.

Two further PRs will build on this. It is part of the "new release process" effort.

@boneskull boneskull self-assigned this Jul 25, 2023
@boneskull boneskull added the chore overhead, tests, dev env, etc. label Jul 25, 2023
@boneskull boneskull changed the title [DRAFT] chore: replace yarn with npm chore: replace yarn with npm Jul 27, 2023
@boneskull boneskull marked this pull request as ready for review July 27, 2023 07:56
},
"dependencies": {
"keccak": "^3.0.0"
"keccak": "3.0.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense 👍

@@ -29,9 +30,6 @@
"devDependencies": {
"serve": "^14.2.0"
},
"resolutions": {
"serve/boxen/type-fest": "^2.13.0"
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kumavis Do you have any memory of the reason behind type-fest being resolved to 2.13 in perf and to 0.21 pretty much everywhere else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless something is using tsc to build or check types when running things in perf, I'm unsure how this could be a problem. type-fest contains no code and does nothing

@naugtur
Copy link
Member

naugtur commented Jul 28, 2023

@lavamoat/yarn-plugin-allow-scripts is a helper for getting allow-scripts to run under yarn3. It should not be affected by this.

@boneskull
Copy link
Contributor Author

boneskull commented Jul 28, 2023

@lavamoat/yarn-plugin-allow-scripts is a helper for getting allow-scripts to run under yarn3. It should not be affected by this.

@naugtur Why is it a private package? How is it consumed?

@naugtur
Copy link
Member

naugtur commented Jul 28, 2023

Yarn copies it over from a GitHub url because the plugin is supposed to be installed before any packages can get installed 🙈

@boneskull
Copy link
Contributor Author

Yarn copies it over from a GitHub url because the plugin is supposed to be installed before any packages can get installed 🙈

how does this even make sense

@naugtur
Copy link
Member

naugtur commented Aug 1, 2023

Yarn copies it over from a GitHub url because the plugin is supposed to be installed before any packages can get installed 🙈

how does this even make sense

I guess that's why npm doesn't have plugins. But it does make sense in the context of what the plugins are for - it means they need to be installed before any package management happens, so they must be a single-file fetchable from URL/

Copy link
Member

@naugtur naugtur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that these are merged I see what I missed before - reviewing each changeset separately I assumed one of the other ones would contain an update to the RELEASE.md file with the updated process description step-by-step so that everyone knows how to proceed with releasing.

@boneskull
Copy link
Contributor Author

@naugtur RELEASE.md is ready for you

Copy link
Member

@naugtur naugtur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thumbsup on the release description. Approving the pr.

(could) I'd prefer to keep the dependency picture (mermaid graph) somewhere and this file seems like a good place for it.

(later) A checklist for the person doing the release (what to look for in the PR etc) should go into this file too.

Used [synp](https://npm.im/synp) to convert from `yarn.lock` to `package-lock.json`.  All resulting `package-lock.json` files are v1 _except_ the root which is v2.
This removes all yarn config, caches, and lockfiles, and changes all scripts to use `npm run` instead of yarn`.  It means `lerna bootstrap` is no longer needed, and `lerna` is not needed (but can still be used) to run scripts across workspaces.  There should only be _one_ lockfile: the root `package-lock.json`.

Note that this change impacts what would be done in #625.  Test fixtures, when installed, should no longer create lockfiles.

A note on "resolutions": these become `overrides` and everything can be done in the monorepo root.

This changeset does not modify CI.
- fix `test:prep` execution
- using `npm`, node/test/projects/1/node_modules will be symlinked and not under vcs
- pin keccak version
- cleanup `allow-scripts` tests (a bit of DRY, fix misuse of `path.join`, make fs cleanup more consistent)
- fix a problem in the `allow-scripts` tests where _not enough_ cleanup was happening
This is an experimental change.

It modifies the Lerna configuration to publish independent packages (without `nx`) using conventional commits.  This will create/update CHANGELOGs and create GitHub Releases for each workspace upon publish.

This is what [Appium](https://github.com/appium/appium) does, and I believe the goals for our release process are nearly identical.  Please look at the releases/tags in that repo for what you get.

To publish, run `npm run publish`.
This encodes the proper `lerna publish` flags within `lerna.json`.  `release-please` will handle creating the GitHub release and updating the changelog, and we just want Lerna to publish what we have.

These flags are essentially the same thing we have currently, sans the `--yes` flag.
- adds a pre-commit hook that runs `eslint --fix` on any JS file on the stage
- adds a commit message check that verifies the commit message is in conventional commits format
- adds `husky install` to workspace root `postinstall` script, to be run via `allow-scripts`
- adds a `prepare` lifecycle script which runs the `rebuild` script
- remove `preversion` script
This disables the `separate-pull-requests` flag, as enabling it adds too much opportunity for human error to befoul the process.

It also enables the `node-workspace` plugin:

> The node-workspace plugin builds a graph of local node packages configured in release-please-config.json and the dependency relationships between them. It looks at what packages were updated by release-please and updates their reference in other packages' dependencies lists. Even when a particular package was not updated by release-please, if a dependency did have an update, it will be patch bump the package, create a changelog entry, and add it to the list of PR changes. Under the hood, this plugin adapts specific dependency graph building and updating functionality from the popular lerna tool.

Finally, the `prepare` script is removed and a `prepublishOnly` script then rebuilds any artifacts and runs a full test suite before the final publish is green-lit.
Use cross-env for cross-platform compat. This does not mean other scripts work across platforms, but we should move in that direction.
@boneskull
Copy link
Contributor Author

I've restored the table in RELEASE.md.

@boneskull boneskull merged commit db62b17 into main Aug 16, 2023
9 checks passed
@boneskull boneskull deleted the boneskull/npm branch January 19, 2024 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore overhead, tests, dev env, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants