Ignore certain dependencies

[broksonic21]

Love this - it just works to add settings.

Is there anyway to do the following using the base expo plugin:

• ignore dev dependencies? or does it always do that
• ignore specific dependencies? I see it's picking up our own internal packages that we depend on and I'd like to ignore those from the listing.

[mateusz1913]

Hi @broksonic21, currently expo plugin uses the following ScanOptionsFactory config

{
  includeTransitiveDependencies: true,
  includeDevDependencies: false,
  includeOptionalDependencies: true
}

So the dev dependencies are ignored now. We didn't add yet the way to modify this config from the level of plugin, but we'll do in future releases.

Also private packages are ignored by default, so if you have some internal package, try to add private: true in their package.json. If that would not work for you, let us know and we'll discuss how to support filtering out non-private packages

[broksonic21]

Thanks - I saw that after. being able to turn off optional and transitive would be nice and what we'd ideally want.

re: private - The issue is that you can't do private: true for packages that come from a different internal repository and still push to github packages to host and use in other repositories. You can, and we do, set this:

 "publishConfig": {
    "access": "restricted",
    "registry": "https://npm.pkg.github.com"
  },

So maybe a better way to phrase is to restrict restricted packages vs privatre packages.

[mateusz1913]

Got it, so we'll need to implement a way to respect such setting. I'll create a feature request issue

[thisisgit]

Hi @mateusz1913 , would setting all above fields to false will return only direct dependencies, i.e. only dependencies field from package.json?
I'm planning to migrate from https://github.com/k-tomoyasu/react-native-oss-license as it requires me to generate licenses every time I update versions or add package. I wonder if disabling all those options would have the same effect of --only-direct-dependency flag of react-native-oss-license.

[mateusz1913]

Hi @thisisgit, I believe yes, however we don't support configuring those options through config plugin yet, that was reported as a feature request a couple of weeks ago, but I didn't have capacity to implement it.

[thisisgit]

@mateusz1913 Awesome, I've looked into the code for a bit and I guess changing this part would make it work?

react-native-legal/packages/react-native-legal/plugin/src/ios/withIosLegal.ts

Lines 15 to 25 in 84fc168

	export const withIosLegal: ConfigPlugin = (config) => {
	withXcodeProject(config, async (exportedConfig) => {
	const licenses = scanDependencies(path.join(exportedConfig.modRequest.projectRoot, 'package.json'));
	writeLicensePlistNPMOutput(licenses, exportedConfig.modRequest.platformProjectRoot);
	return exportedConfig;
	});
	config = addSettingsBundle(config);
	config = registerLicensePlistBuildPhase(config);
	return config;
	};

To maybe something like this:

 // `options` passed from the user. It can also have type of `void` for backward compatibility
 export const withIosLegal: ConfigPlugin<ScanPackageOptions | void> = (config, options) => { 
   withXcodeProject(config, async (exportedConfig) => { 
     const optionsFactory: Types.ScanPackageOptionsFactory | undefined = options ? () => options : undefined;
     const licenses = scanDependencies(path.join(exportedConfig.modRequest.projectRoot, 'package.json'), optionsFactory); 
  
     writeLicensePlistNPMOutput(licenses, exportedConfig.modRequest.platformProjectRoot); 
     return exportedConfig; 
   }); 
   config = addSettingsBundle(config); 
   config = registerLicensePlistBuildPhase(config); 
   return config; 
 }; 

And from the config file, user can use:

[
   'react-native-legal',
   {
     includeTransitiveDependencies: false,
     includeDevDependencies: false,
     includeOptionalDependencies: false,
   },
],
// or this as user can opt to use default options
['react-native-legal']

Android plugin + the wrapper for both platform plugins need to be updated as well but this is just to confirm if the solution is valid.
Let me know how you think and thanks for your hard works!

[mateusz1913]

Hi @thisisgit, yes that's the way to go! I have pushed #111 and we'll try to merge and release it next week

[thisisgit]

🙌🙌 Thanks @mateusz1913 !