Trouble with theme lint at "install JS Dependencies” step

I copied [package.json](https://github.com/discourse/discourse-theme-skeleton/blob/main/package.json) from the latest discourse-theme-skeleton/package.json at main · discourse/discourse-theme-skeleton · GitHub

It’s not big:

{
private: true,
devDependencies: {
@discourse/lint-configs: "2.21.0",
ember-template-lint: "7.7.0",
eslint: "9.27.0",
prettier: "3.5.3",
stylelint: "16.19.1"
},
engines: {
node: ">= 22",
npm: "please-use-pnpm",
yarn: "please-use-pnpm",
pnpm: "9.x"
},
packageManager: "pnpm@9.15.5"
}

Linting works with my attempts to run the Right Stuff locally, but in github, I get this:

Run yarn install --frozen-lockfile
error This project's package.json defines "packageManager": "yarn@pnpm@9.15.5". However the current global version of Yarn is 1.22.22.

Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.

And that’s in the “install JS Dependencies” step, so it would seem like this can’t be because of anything I’ve done?

Here’s my code: GitHub - pfaffman/discourse-custom-homepage-for-groups: Discourse theme component to change home page based on user's primary group

1 Like

FWIW this looks like the problem step?

Yarn should not be running full stop?

(PS don’t you just love it when you take 15 minutes to update a repo, then some meta issue takes you hours :sweat_smile: )

This is your problem:

Remove your yarn.lock file from the repo but leave (and update!) your pnpm-lock.yaml file

Bonus points :sports_medal: Ideally this should have been a PR so you haven’t got failing CI on your main branch.

2 Likes

That’s true. I’m starting to try to remember to do that; it’s just not automatized yet. I’m up to doing it about 30% of the time. :slight_smile:


Now I’ve got this:

Run pnpm install --frozen-lockfile
 ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation. The current "settings.autoInstallPeers" configuration doesn't match the value found in the lockfile

Update your lockfile using "pnpm install --no-frozen-lockfile"

So then I did what it told me, and now I get:

Run bundle install
Don't run Bundler as root. Installing your bundle as root will break this
application for all non-root users on this machine.
Could not locate Gemfile

But when I do this:

 (main *) pfaffman@noreno:~/src/pfaffman/discourse-custom-homepage-for-groups$ cp ~/src/discourse-repos/discourse-theme-skeleton/pnpm-lock.yaml .
 (main *) pfaffman@noreno:~/src/pfaffman/discourse-custom-homepage-for-groups$ git add pnpm-lock.yaml
 (main +) pfaffman@noreno:~/src/pfaffman/discourse-custom-homepage-for-groups$ git commit -m 'their pnpm lock'
[main e195a2e] their pnpm lock
 1 file changed, 1 insertion(+), 1 deletion(-)
 (main) pfaffman@noreno:~/src/pfaffman/discourse-custom-homepage-for-groups$ git push

and I’m sure their repo is up to date.

See? And it even is reminding me that I’m irresponsibly working on the main branch.

Guessing this is just a stale pnpm-lock file … run an install in the directory.

But when I ran pnpm install --no-frozen-lockfile and then used the new lock file, github then gave me the bundler error. I should be able to use the one in discourse-theme-skeleton, right?

Add the Gemfile

1 Like

Wait. The Gemfile is for ruby, right?

But here:

pfaffman@noreno:~$ cd src/discourse-repos/discourse-theme-skeleton/
 (main) pfaffman@noreno:~/src/discourse-repos/discourse-theme-skeleton$ cp pnpm-lock.yaml  Gemfile.lock Gemfile package.json stylelint.config.mjs ~/src/pfaffman/discourse-custom-homepage-for-groups/

That’s the stuff we need, right? Turns out that stylelint.config.mjs was out of date, so that’s something.

Anyway, I’ve still got

 ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation. The current "settings.autoInstallPeers" configuration doesn't match the value found in the lockfile

Guess it’s for any specs, it’s required by the CI script.