Skip to content
This repository has been archived by the owner on Oct 10, 2022. It is now read-only.

Detect package managers #13

Open
JGAntunes opened this issue Mar 30, 2021 · 2 comments
Open

Detect package managers #13

JGAntunes opened this issue Mar 30, 2021 · 2 comments
Labels
type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@JGAntunes
Copy link
Contributor

JGAntunes commented Mar 30, 2021

Support detection of package managers such as yarn and npm based on project files and env variables set.

See - https://github.com/netlify/build-image/blob/be42e453d6c8f171cc2f654acc29c0a8b60e6d93/run-build-functions.sh#L508-L521

This would require a couple of changes.

We would need to change the package API to receive the env var config object (in this case we're only interested in the all entry from the @netlify/config output). In order for the buildbot to pass in this data we would need a new cli field (--config-env? --env?) which could be used to send a JSON serialized env object similar to - https://github.com/netlify/buildbot/blob/master/bot/configuration.go#L127.

In terms of how we want to detect package-managers I would like to take a page out of the framework-info book relying on an interface that's easy to extend with new package managers, by relying on a simple JSON format such as:

{
  "id": "npm",
  "name": "npm",
  "detect": {
    "env": {},
    "configFiles": ["package.json"]
  }
}
{
  "id": "yarn",
  "name": "yarn",
  "detect": {
    "env": {
      "NETLIFY_USE_YARN": true
    },
    "configFiles": [
      "package.json",
      "yarn.lock"
    ]
  }
}

Initially we could make the detection based on env vars OR configFiles. With env vars taking precedence over files. This is probably somewhat of a simplistic approach for the future but I guess we can iterate later on if needed.

The detected package managers would be outputted in a "priority" based array, similar to framework-info, e.g:

{
  "packageManagers": [
    {
      "id": "yarn",
      "name": "yarn"
    },
    {
      "id": "npm",
      "name": "npm"
    }
  ],
  (...)
}

Wondering what you all thinkg @ehmicky @erezrokah @eduardoboucas?

@JGAntunes JGAntunes added the type: feature code contributing to the implementation of a feature and/or user facing functionality label Mar 30, 2021
@JGAntunes JGAntunes changed the title Detect JS package managers Detect package managers Apr 15, 2021
@erezrokah
Copy link
Contributor

I like the JSON format. For framework-info plugins field and for the plugins.json compatibility field we use JSON schema with custom keywords:
https://github.com/netlify/framework-info/blob/47f38b73435338fe3ab2c83605d5c69312405203/src/frameworks/next.json#L22
https://github.com/netlify/plugins/blob/3d8882492b16f96f0af02968335959b03cd4dee5/site/plugins.json#L361
https://github.com/netlify/plugins/blob/3d8882492b16f96f0af02968335959b03cd4dee5/site/plugins.json#L431

This makes the implementation very simple https://github.com/netlify/framework-info/blob/47f38b73435338fe3ab2c83605d5c69312405203/src/plugins.js#L13

I wonder if can use the same approach. I think that might allow us to support both OR, AND and more complex composition of conditions without too many code changes.

@ehmicky
Copy link
Contributor

ehmicky commented Apr 15, 2021

Great idea!
Adding an --env CLI flag sounds nice. Also, both @netlify/build and @netlify/cli have that flag too.
I like the declarative format approach! Keeping it similar to framework-info also makes sense.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

No branches or pull requests

3 participants