`*ependencies` bits in `package.json` questionable

[sogaiu]

Currently, *ependencies bits in package.json are like:

tree-sitter-clojure/package.json

Lines 12 to 17 in 262d6d6

	"dependencies": {
	"nan": "2.14.2"
	},
	"devDependencies": {
	"tree-sitter-cli": "0.19.3"
	},

Based on recent investigations it has started to seem like these bits are unnecessary.

IIUC, what is relevant ATM is that the generated .c source use ABI 13.

This is achievable with more recent versions of the tree-sitter cli by using the generate subcommand with the --abi option and an appropriate number. Further, there is no need to use npm to obtain the tree-sitter cli as it can be compiled from source fairly easily (once you know how), there are also binaries downloadble from the tree-sitter repository releases page, and some distributions even have packages.

My current leaning is toward removing dependenices and devDependencies and provide instructions regarding installation and usage of the tree-sitter cli that don't suggest that npm is necessary.

Some of the advantages of doing this include:

• Simpler instructions (as use of npm complicates things unnecessarily)
• Less churn (see here for some related discussion)

I suspect this should help with ongoing maintenance as returning to pay attention after some period of inattention should become easier.

[sogaiu]

3daa97f (on the dev branch) removes the *ependencies info from package.json.

[dannyfreeman]

Should we close these issues now that they are on the dev branch? Or wait until they make it to master?

[sogaiu]

I was leaning in favor of the latter option -- waiting for the changes to make it to the release-related branch.

[sogaiu]

I've created a label with text candidate-on-dev.

I've started using it to label an issue (perhaps also pr) if there is candidate code to address it on the dev branch.

[dannyfreeman]

That is fine by me. It's getting difficult to keep track of them all, so that label will help.

[sogaiu]

I agree it's getting difficult to track.

Perhaps it's good to consider how much to put on dev at once.

Not sure what a good criteria might be but the current amount might be too much -- perhaps another thing to keep in mind is the magical number 7 +/ 2.

[sogaiu]

Looking at the draft CHANGELOG I wonder if that file could become a home for some outline or plans for future activities.

[sogaiu]

I wonder if there's a good way for each of us to indicate to others that there are specific issues / prs we'd like review / feedback on.

Initially I though possibly a please-review tag might be worth considering. Although the tag idea does have a benefit that one can get a filtered view of items awaiting review / feedback on, it doesn't really give an idea of who wants the review / feedback.

I suppose there could be a tag per person...starting to sound too hacky perhaps.

I guess this tends to become an issue when there are too many things and consequently the probability of something dropping through the cracks increases.

[NoahTheDuke]

For @pest-parser, we have a random "maintainer" chosen to do triage/reviewing of new PRs when they're made.

[sogaiu]

Nice - though I guess this is more meaningful when there are more than a few participants :)

[sogaiu]

The changes relevant to this issue can now be seen in 44ed28f.

[sogaiu]

As mentioned above, addressed in 44ed28f.