-
Notifications
You must be signed in to change notification settings - Fork 80
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
Implement CI checks pipeline #23
Comments
Regarding the |
@hdgarrood I'd go for making things simple and ask to rename the package when changing the repo in the manifest. I'm aware that many packages went through this (e.g. |
It's a bit unfortunate that we'll end up with lots of essentially inaccurate information that way, though, and also I don't think there's anything to stop someone else coming in and taking a repo name which previously had a redirect set up. I don't think what I'm proposing is too complicated: given a let
-- A map of repos "claimed" by each package
reposClaimed :: Map PackageName (List Repo)
reposClaimed =
map (List.nub <<< Map.values) packages
-- flip it around to map repos to the packages that claim them
reposClaimedBy :: Map Repo (List PackageName)
reposClaimedBy =
reposClaimed
# Map.toList
-- gets us a List (Tuple (List Repo) PackageName)
# map swap
-- gets us a List (Tuple Repo PackageName)
# List.concatMap (\(Tuple repos pkgName) -> map (\r -> Tuple r pkgName) repos)
-- turn each tuple into a Map Repo (List PackageName)
# map (\(Tuple repo pkgName) -> Map.singleton repo (List.singleton pkgName))
-- combine
# Map.unionWith (<>)
in
for_ (Map.toList reposClaimedBy) \(Tuple repo pkgNames) -> do
when (List.length pkgNames > 1) do
throwError $ show repo <> " is claimed by " <> show pkgNames |
@hdgarrood thanks for the example. That looks good, but the situation that I want to prevent with the check is not packages sharing a repo (which should actually happen in the case of packages published from monorepos) but some situation in which person |
Oh right, I see, thanks. Did you consider storing a list of maintainers for each package? That is, a list of people who are permitted to add new versions. By default, the first person to claim a package name would become the sole maintainer, and they can subsequently add others. I think that's how most package registries work. |
Could we add a check for if a major or minor bump is omitted? For example, can we diff the package's API and check for:
|
@hdgarrood yeah having a list of maintainers for each package sounds like the best way to go. The check would work such that only maintainers that included in the list for the previous version would be able to add releases - this means that before a new maintainer is allowed to publish a release there should be a previous release where one of the current maintainers adds the new maintainer to the list. @milesfrain that would be nice. How would we implement this though? |
Is it worth being able to store certain package information in a separate place, where it's not tied to any specific version? I feel like adding or removing a maintainer ideally shouldn't require a release. I think API diffing should be implemented inside the compiler, it's going to be difficult to get right otherwise. For instance, changing the name of a type variable shouldn't count as a breaking change. |
@hdgarrood you mean something like storing a |
I think we might want to make a space for storing information about a package which isn’t tied to any particular version, or maybe won’t be present when a version is first uploaded, and I don’t think the list of maintainers is the only such information. For example, I think deprecations (“$user deprecated versions X-Y of this package for $reason”) also fit into this category. Arguably so does the repository homepage. |
Makes sense. Let's have a |
Sounds good to me |
There are a bunch of things that we need to enforce in CI, so that we don't add packages that don't follow the criterias we defined.
Checks we want to run for every package:
name
satisfies the constraints (as defined in Package name constraints #3)repo
value is the same for all the versions of a package (to prevent packages "stealing" package names)license
is a valid SPDX expression (see Implement SPDX license expressions #13)repo
is on GitHub (see Only accept packages from GitHub? #15)reject packages with ES6 syntax in their FFI (see #24)lib
Target["src/**/*.purs"]
in itslib
Target (see here)This issue is about:
The text was updated successfully, but these errors were encountered: