pkg.pr.new support

[Aslemammad]

We love publint. I wonder if we would be able to paste a pkg.pr.new url like http://pkg.pr.new/vite@main and have it linted.

It'd be nice to have tarballs checked by publint.

And I'm also thinking about adding a new option to pkg.pr.new where users can run pkg-pr-new publish --publint where they would have their package linted after publish.

[bluwy]

That sounds doable. Currently the code is fetching a tarball from npm and linting it, so it should be a matter of having a custom UI to pass a different tarball URL to be linted.

publint/site/src/utils/worker.js

Lines 17 to 19 in 5ae869f

	tarballUrl = getNpmTarballUrl(npmPkgName, npmPkgVersion, {
	registry: import.meta.env.VITE_NPM_REGISTRY
	})

publint/site/src/utils/worker.js

Lines 38 to 61 in 5ae869f

	let files
	try {
	const tarBuffer = inflate(resultBuffer).buffer // Handles gzip (gz)
	files = untar(tarBuffer) // Handles tar (t)
	} catch (e) {
	postMessage({ type: 'error', data: 'Failed to unpack package' })
	console.error(e)
	return
	}
	const vfs = createTarballVfs(files)
	postMessage({ type: 'status', data: 'Linting package...' })
	// The tar file names have appended "package", except for `@types` packages very strangely
	const pkgDir = files.length ? files[0].name.split('/')[0] : 'package'
	const { messages } = await publint({ pkgDir, vfs })
	const pkgJson = JSON.parse(await vfs.readFile(pkgDir + '/package.json'))
	postMessage({
	type: 'result',
	data: {
	messages,
	pkgJson
	}
	})

And I'm also thinking about adding a new option to pkg.pr.new where users can run pkg-pr-new publish --publint where they would have their package linted after publish.

That sounds neat too. Depending on how you're planning to display it, if it's only in the CLI, I guess it could be easily glossed over. In the past I found users prefer putting it in their CI that blocks or exits code 1 if something fails, so that's more impactful. It's easier to manage versions too.

Another option perhaps is that it can print out a publint.dev link so that they can open and view the results directly.

[Aslemammad]

so it should be a matter of having a custom UI to pass a different tarball URL to be linted.

Nice, so it's easy! Maybe we can add a regex and see if it's a url, then we just do things directly on that url. What do you think?

Another option perhaps is that it can print out a publint.dev link so that they can open and view the results directly.

I think this is way better! Maybe in our comments we just give a lint to the user, so when they navigate it they see a collection of preview packages that they can click on and see the lintings. maybe that can be a new route in publint?

[bluwy]

Yeah I think we'd need to figure out a route for both features. When pasting a link to the search input, we can navigate to a route that handles the specific link to the tarball. I'm not quite sure yet what that could look like, perhaps:

1. https://publint.dev/registry?tarball=http%3A%2F%2Fpkg.pr.new%2Fvite%40main
2. https://publint.dev/registry/pkg.pr.new/vite@main
3. https://publint.dev/pkg.pr.new/vite@main

Some kind of syntax that allows for other registries in the future. A mix of no1 and no2 could be nice to allow custom URLs, but also have a cleaner link for supported registries 🤔

What are the patterns for pkg.pr.new links could look like? There's http://pkg.pr.new/vite@main. and I guess http://pkg.pr.new/vite@SHA, http://pkg.pr.new/@scope/my-pkg@main, etc. Are there any other parameters / search params that can be used in the link?

[Aslemammad]

I love no 3 and 2, because that way, we can have a catch-all route and then forward whatever comes after the / to pkg.pr.new! And they are cleaner.

so https://publint.dev/pkg.pr.new/vite@main -> /vite@main -> https://pkg.pr.new/vite@main

This way you won't need to handle all the edge cases of pkg.pr.new routing.

Are there any other parameters / search params that can be used in the link?

No we do not have any of that.