Respect package.json in sub-folders

[leo]

Currently, it seems like greenkeeper only respects the package.json within the root directory of a certain repo. If you ask me, it would be awesome if it would also respect all others within in sub-folders.

As an example: When building a Yeoman generator, most people add something like a boilerplate which allows developers to easily scaffold the base of their app. And those boilerplates of course also contain a package.json (since dependencies need to be installed somehow).

[boennemann]

Hey @leo,

thanks for your feature request. It is true that Greenkeeper currently only monitors a package.json at the root of the repository.
Wee see that there are valid use cases for package.json files in other places, but currently it's our top priority to nail the npm module/Greenkeeper core experience.
I realize that this might not be the most satisfying answer, but we want to get things right before tapping into too many other fields, that might bring us further away from a thought through, smooth and stable core experience.

Thanks for understanding and giving Greenkeeper a try.

Best,
Stephan

[cjb]

Hi, just a +1 -- I'm not able to use Greenkeeper without this.

[leo]

@cjb Awesome! 😊 But:

[Awk34]

+1 to this. It would be great if there were a config var to manually specify other manifest files. I'm using Greenkeeper on the generator portion of angular-fullstack/generator-angular-fullstack, but it would be great if I could also specify our templates/_package.json file, which is used as the manifest file for the scaffolded project; but it might be out of the scope of Greenkeeper, since the template manifest file uses EJS to include/exclude dependencies depending on which options the generator's user chooses. I'm assuming Greenkeeper tries to parse the JSON, which wouldn't work without getting rid of the EJS code first.

[leo]

@Awk34 Yes, exactly! That would be so awesome for generators and boilerplates in general.

[stipsan]

There's other valid reasons you could face.
For instance: https://github.com/electron-userland/electron-builder#two-packagejson-structure

Other use cases would be projects where you got multiple deploy targets (heroku nodejs apps, react-native and electron apps) where it makes sense to use the same git repo for all the sourcecode.
If you're developing in react you may share some of your code in all of the deploy targets but you have very different dependencies and devDependencies making it impractical to use a root package.json for everything.
I almost regret trying out greenkeeper as now that I've tasted the forbidden fruit I've ended up with splitting my projects into multiple repos.
The benefit of not having to manage dependencies manually heavily outweighs the benefit of having all your codebase in the same repo…

[Awk34]

@stipsan that reminds be of Babel as well: https://github.com/babel/babel/tree/master/packages (monorepo)

[jgillich]

If you only have one package.json, you can move it to the root and link it from the sub dir (might also work the other way around), then do greenkeeper disable && greenkeeper enable.

Edit: Doesn't work the other way around, the actual package.json must be in the root and not the symlink.

[danielsiwiec]

I'd also like to see this feature

[ZauberNerd]

I'm also running into this issue at the moment.
We have a react-native project with several services inside (mobile app, graphql, etc) and they all have their own package.json.
It would be great if we could have a globbing pattern or something similar in the config to support this use-case.

[ghost]

Suggesting an incremental feature if it could work as a stepping stone... it'll be great if we could initially specify the directory where package.json is (e.g. a .greenkeeper config file in root would work for us).

Background: I work on a project where a single repo contains multiple projects in different languages, and splitting those out to separate repos will incur a whole ton of work on CI config, server config, etc. plus all developers will need to spend a fairly significant amount of time updating their local setup as well... hence we're holding off until this is implemented in some form.

[rkuykendall]

Greenkeeper looks great, and I'd love to be able to use it in my repo with different python/node subfolders. Let me know if there is anything I can do to help.

[rarkins]

My need is to monitor 2 package.json files within the same repo

[StephanBijzitter]

Hello!

We've recently started using Greenkeeper to keep our private NPM repository up to date, but the effect is limited because we have a structure that is designed to limit maintenance to a minimum.

The root of our project contains a package file with developer dependencies, that are used by all (or a large majority) of our NPM modules. The modules themselves are in a directory called modules.

This means we have package files in the following directories:

• root/package.json
• root/modules/module-a/package.json
• root/modules/module-b/package.json
• et cetera

Currently, Greenkeeper only checks the first package file in the root. I would hereby like to request a configuration option to scan a glob for package files, making the location(s) completely customizable.

I have not yet taken a look at the code, but if you think a third party could implement this, I would be able to get our management to give this more priority, allowing us to create this feature. If that's the case and you already have an idea of where this should be implemented, please do provide us some filenames.

Quoted content from #308, so that it can be closed.

[janl]

Proposa here: #594

[janl]

Good news everyone! 🎉

We have just deployed beta support for multiple package.jsons per repo and we are soliciting early community feedback before making a more formal announcement. 📯

If you have any trouble with this, or just have a questions please reply here or email support@greenkeeper.io. 📫

---

Quickstart 🏃‍♀️

Like enabling Greenkeeper for regular repos, adding it to the list of enabled repos in your GitHub App settings page for Greenkeeper will start the multiple-package.json-support.

If it is already enabled, you can disable and re-enable it to get started.

Alternatively, you can push a valid greenkeeper.json file (see below) to the root of your repo to enable multiple-package.json-support.

How it works 🤔

We’re in the process of writing proper docs, so this is just a quick reference. 📎

When you enable a repo and Greenkeeper detects that it has multiple package.json files, your initial PR to start Greenkeeper includes a default greenkeeper.json file. That file determines the way you will get updates. Here is what that looks like:

{
  "groups": {
    "default": {
      "packages": [
        "packages/frontend/package.json",
        "packages/backend/package.json"
      ]
    }
  }
}

Greenkeeper introduces the notion of groups to, well, group different package.json files together. The default case is a default group that includes all package.json files we can find.

In the case above, there are two package.json files in subdirectories. From looking at this, we could imagine that it is a frontend web app that uses JS, and a Node backend app. With the config file above you will get an issue/PR when a dependency in any or both package.json files is updated, with a commit, that updates the dependency in both files.

Now, given the nature of the project, it might be, that you want to update dependencies differently in the frontend and in the backend. There might even be entirely different teams working on this.

In that case, you can update your new greenkeeper.json config file, to look like this:

{
  "groups": {
    "frontend": {
      "packages": [
        "packages/frontend/package.json"
      ]
    },
    "backend": {
      "packages": [
        "packages/backend/package.json"
      ]
    }
  }
}

With this configuration, you will get separate issues/PRs for the different groups, making the backend and the frontend teams independent of each other.

You can have as many groups as you like. There are a few rules for the group names that you can pick and Greenkeeper will open issues with detailed error descriptions, if you introduce errors in your greenkeeper.json.

---

We’d like to thank everyone for their input and patience and we’re looking forward to see how this works for you. 🤗 ❤️ 🌴

PS: We’re now looking at the reverse of this feature: grouping updates that are released from a Monorepo: #711

[mAAdhaTTah]

How does this work with lockfiles? And does it work with Yarn Workspaces (where the lockfile for the entire repo is solely in the root)?

[janl]

@mAAdhaTTah excellent question. For Greenkeeper, lockfile handling, including yarn, is done in https://github.com/greenkeeperio/greenkeeper-lockfile/ — And we are currently working on getting that updated to support monorepos: greenkeeperio/greenkeeper-lockfile#140

We’ll make sure to make this compatible with yarn workspaces, but no promises yet on when that’s all done.

[mAAdhaTTah]

Great, I'll subscribe to that PR. Would, in the meantime, manually updating the lockfile in the PR'd branch suffice?

[janl]

Great, I'll subscribe to that PR. Would, in the meantime, manually updating the lockfile in the PR'd branch suffice?

indeed.

[rkuykendall]

I switched to Dependabot many months ago. But hey, congratulations on over two full years! I'll un-sub now so you won't have to hear from me again.

[janl]

https://blog.greenkeeper.io/announcing-greenkeeper-3-1504f5113998