Typescript Compliance

[kanthesha]

We want to make sure that for a given project:

• The project contains a tsconfig.json file, and the content of the file matches the same file in the module template
• The project contains a tsconfig.build.json file, and the content of the file matches the same file in the module template
• The project contains a tsup.config.ts file, and the content of the file matches the same file in the module template
• The project contains @types/node, ts-node, tsup, and typescript as dev dependencies, and the versions match the same dev dependencies as in the module template
• The project contains the same build and build:types package scripts as in the module template
• The project's package.json has an exports field, and all of the keys in exports should be present in the project's exports field and the values should match.
• The project's package.json has a main field, and its value should match the same field in the module template.
• The project's package.json has a module field, and its value should match the same field in the module template.
• The project's package.json has a types field, and its value should match the same field in the module template.
• The project's package.json has a files field, and its value should match the same field in the module template.
  If project's package.json contains a lavamoat field, and that contains allowScripts, then a tsup>esbuild property should be present and should match the same one in the module template.

Fixes #8

[socket-security]

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report↗︎

[mcmire]

I forgot how many bullet points were in this ticket 😅 Good work on refactoring some of these rules. I left some suggestions on how we can simplify that code even further potentially. I need to still go through the test files and check them but this should be enough for now I imagine!

[mcmire]

Getting close! All of the logic looks correct to me, but I do want to make sure that the deep containment logic is being tested appropriately.

[mcmire]

What do you think about adding main to the set of properties we're passing here? Same for below:

Suggested change

	buildPackageManifestMock(),
	);
	const project = buildMetaMaskRepository({
	shortname: 'project',
	directoryPath: path.join(sandbox.directoryPath, 'project'),
	});
	await writeFile(
	path.join(project.directoryPath, 'package.json'),
	buildPackageManifestMock(),
	buildPackageManifestMock({
	main: 'main.js',
	}),
	);
	const project = buildMetaMaskRepository({
	shortname: 'project',
	directoryPath: path.join(sandbox.directoryPath, 'project'),
	});
	await writeFile(
	path.join(project.directoryPath, 'package.json'),
	buildPackageManifestMock({
	main: 'main.js',
	}),

[kanthesha]

It is already there as a default set of properties. The suggested change may make it easy for the reader to understand what we are exactly passing as a main property! But at the same time, for some, it may also confuse, when it is already there, why this test is overriding with something else, when there's no need.

[mcmire]

I suppose it depends on how familiar the reader is with these tests. Someone who is familiar may not feel the need, if they already know that buildPackageManifestMock includes main.js in its list of defaults. I think it will be more common that these tests will appear fresh to even us, so the easier we can make it for ourselves to understand the test, the better.

If you think it would be confusing, though, then would it work to choose a different value in this case? Something like index.js instead of main.js, perhaps.

[mcmire]

A few more minor things. I did test this out though and everything seems to work!

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@types/lodash@4.14.202	None	0	862 kB	types

View full report↗︎

[mcmire]

Looks good!