The code is licensed under MIT, which requires attribution and including the license. That means we should avoid copy-paste. Can we find a way to include this as a dependency? One approach would be to add it to package.json:

"thumbhash": "git+https://git@github.com/evanw/thumbhash.git",

And then to symlink from node_modules/thumbhash into this folder.

Alternately, we could do the whole third_party folder thing and include the LICENSE in there.

Expo-image has the same copy-paste with single-line mention of the original author: https://github.com/expo/expo/blob/d4b007465df538de2ae5abb36dc768caf9865e97/packages/expo-image/ios/Thumbhash.swift#L4

If we really want to add the licensing stuff, the git+ dependency would be very cumbersome to link it to the native code. The only reliable and not overcomplicated way, on which we won't spend too much time, would be to create the third_party folder directly in the expo-modules/thumbhash/{ios,android}/ directories.

If we really want to add the licensing stuff, the git+ dependency would be very cumbersome to link it to the native code.

Not sure why? Should be possible with symlinks to just reference the files you want in node_modules

The only reliable and not overcomplicated way, on which we won't spend too much time, would be to create the third_party folder directly in the expo-modules/thumbhash/{ios,android}/ directories.

That seems fine

If we really want to add the licensing stuff, the git+ dependency would be very cumbersome to link it to the native code.

Not sure why? Should be possible with symlinks to just reference the files you want in node_modules

• We're in monorepo so we cannot be sure that hoisting won't break symlinks (even with future dependency changes). We could use something that expo-autolinking does for resolving correct paths but this requires some groovy + ruby scripting for gradle/cocoapods which adds complexity
• The upstream repo can change (unless we fork it - that might be a good idea)
• Files in the repo are package-private (no public modifier) so I'd need to patch-package them (or use a fork)

The current solution seems fine, but just following up here:

The upstream repo can change (unless we fork it - that might be a good idea)

We generally set a specific commit hash / tag / branch when we do this, eg. take a look at how we depend on olm in `native:

"olm": "git+https://github.com/CommE2E/olm.git#v0.0.9",

Files in the repo are package-private (no public modifier) so I'd need to patch-package them (or use a fork)

Not familiar with this or why it matters... if you're checking out a Git repo just to access some file in it, I don't think package.json needs to be considered. For olm in native, I believe we include a Git repo that doesn't even have a package.json

Not familiar with this or why it matters... if you're checking out a Git repo just to access some file in it, I don't think package.json needs to be considered. For olm in native, I believe we include a Git repo that doesn't even have a package.json

I mean native Swift/Java files.

Fortunately on web, we can simply add the thumbhash npm dependency which has all stuff that we need

It doesn't really matter, but yeah, your way seems more correct