Skip to content

Package name constraints #3

Closed

Description

@hdgarrood

I would like to be quite strict about what is allowed as a package name. In particular, there are some packages with uppercase characters in this repo right now and I'd like to enforce that package names are lowercase. Partially because it's very annoying to have to remember the casing of package names, and partially because it's potentially a vector for attacks with similar-looking characters, like uppercase I vs lowercase l.

Here's what bower has to say about package names (source):

  • Must be unique.
  • Should be slug style for simplicity, consistency and compatibility. Example: unicorn-cake
  • Lowercase, a-z, can contain digits, 0-9, can contain dash or dot but not start/end with them.
  • Consecutive dashes or dots not allowed.
  • 50 characters or less.

I'd like to keep the restriction that the only allowed characters are a-z, 0-9, dot, and dash, and ban consecutive dots and dashes. There's an argument to be made that 50 characters is not enough (especially as the purescript- prefix alone takes 10 characters) but I think we should have an upper limit, so 50 is probably sensible as a starting point for now, and we can always relax it later.

Thoughts on implementing the above as part of CI?

Activity

  1. f-f commented on Mar 15, 2020

    @f-f
    Member

    @hdgarrood I'm working on the code for importing all of Bower's package definitions here - I'll shortly open a PR and get back on all the things

  2. hdgarrood commented on Mar 15, 2020

    @hdgarrood
    ContributorAuthor

    awesome :)

  3. f-f commented on Mar 16, 2020

    @f-f
    Member

    @hdgarrood I agree with your analysis, and I'd also like to:

    • forbid dots from package names (right now I don't think there are any)
    • drop the compulsory purescript- prefix because as you noted it's already taking lots of space if we're limiting size to 50 chars, plus it's quite unnecessary as I noted in Import from Bower PoC, the Package type and Package Sets #4
  4. f-f commented on Apr 25, 2020

    @f-f
    Member

    As discussed in #4, we should handle this by having a simple check (I think a regex should be enough) in CI that verifies the constraints we want to enforce. I think the constraints we have so far are a good start, so I'll pivot this issue to "implement the check in CI", and we can always adjust the constraints as we go

  5. added this to the v1 milestone on May 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions