Skip to content
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

Deal with 3rd Party vendor files #110

Open
AccaliaDeElementia opened this issue Jun 19, 2018 · 2 comments
Open

Deal with 3rd Party vendor files #110

AccaliaDeElementia opened this issue Jun 19, 2018 · 2 comments

Comments

@AccaliaDeElementia
Copy link
Member

We need a way and a policy for dealing with third party vendor files such as ckeditor for rich text editing.

Discussed options to date:

  • Git submodules
    • met with firm negative reception my two of three team members in the discussion
  • use a package manager
    • which one? what if there are no official packages from a vendor? what if the package is abandoned?
  • Just check in vendor packages and promise not to touch them
    • cool reception from one team member on suggestion, negative from a second and indifferent from the third (unless i am wrong)
@AccaliaDeElementia
Copy link
Member Author

Alternate idea:

  • Use 3rd party CDN for all third party web code (cloudflare runs a reputable one, as does Google)

@Bluenaxela
Copy link
Contributor

Bluenaxela commented Jun 19, 2018

My perspective on options is as follows:

  • "check in vendor packages"
    • Strongly opposed for anything but very early experimentation, too messy.
  • "Git submodules"
    • Has issues, but in spite of that prefer over checking in vendor packages.
  • "package manager"
    • For cases where official npm packages exist, I consider this a very good idea.
    • For cases where official npm packages do not exist, this is less ideal, but we could consider maintaining our own unofficial packages, referenced by Git URL.
    • I'm reluctant about the notion of pulling in non-npm package management systems. Too many package managers is like too many cooks.
  • "3rd party CDN"
    • I consider this good for things loaded by the browser, conditional on the following all being true:
      • We use integrity checks (most importantly)
      • The URL is versioned
      • The URL is official for the library in question (exceptions could be made if we have reason to be sure the URL won't get changed/removed)

The thought also comes to mind that, longer term, for any of the above cases except official npm packages, where npm already handles this, we ought to plan to have a way to be informed if such a dependency has known security issues an update would fix. Maybe by some sort of CVE checking running automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants