chore: fix package bundling

[lveneris]

No description provided.

[lveneris]

@alexei I don't know who the other maintainers are so, mentioning you in this here.

[alexei]

What problem does this address?

[lveneris]

@alexei the fact that package bundling is not done correctly, as the name implies. Currently, the source code is included with bundles, whereas it should be the distribution channel exclusively. This fixes that.

[alexei]

it should be the distribution channel exclusively

Why?

[lveneris]

@alexei Because that's how package distribution works. You package the metadata and production-ready version of the library. The source code is already available in the repository, and including it adds unnecessary bundle size and slows down dependency installation.

[alexei]

@alexei Because that's how package distribution works.

Hehehe, if that were true, then why is my basic React app using 300 MB of disk space?

---

The source code is already available in the repository, and including it adds unnecessary bundle size and slows down dependency installation.

1. If you think the source code should not be included, then I guess main should be updated as well; keeping it beats the argument you're making. From the docs:

Certain files are always included, regardless of settings:
...
The file in the "main" field

2. This PR not only supersedes Update .npmignore #204 but removes the need for a .npmignore file altogether like you mentioned at one point; in this case, then perhaps this PR should drop .npmignore
3. It's not clear to me whether the files key is a feature of the npm repository, or the npm CLI; if it's the latter, then that complicates things; do you have any docs on this?

[lveneris]

Hehehe, if that were true, then why is my basic React app using 300 MB of disk space?

I have no idea, because react doesn't use anywhere near that much space. Seems like a you problem. Although, altogether, that is a logical fallacy - how can you disprove a statement using one edge case?

main should be updated as well; keeping it beats the argument you're making.

It can be, yes, I just wasn't sure whether you elected to have it like that in the first place for clarity, and removing it wouldn't pose too much difference.

This PR not only supersedes #204 but removes the need for a .npmignore file altogether

Indeed it should. I'll do that.

It's not clear to me whether the files key is a feature of the npm repository, or the npm CLI

What do you mean by "a feature of the npm repository"? The files directive is part of the package manifest standard and is honoured by all major bundlers.

[lveneris]

@alexei Status?

[alexei]

@Nytelife26 sorry - I didn't have time to verify this and I don't consider it urgent anyway

[msimerson]

I would pick this up if I had an indication my PR would get merged. I agree that removing .npmignore (blacklist) and adding the files that should be published on npm in the code tab should be specified.

I'd be more inclusive and also include CONTRIBUTORS.md, because it's the friendly thing to do. Or, move them into the package.json.

[lveneris]

I would pick this up if I had an indication my PR would get merged. I agree that removing .npmignore (blacklist) and adding the files that should be published on npm in the code tab should be specified.

There have been no updates other than for licensing in the past 3 years. I believe it's safe to assume the project will not be actively maintained, which is fine, because the ecosystem doesn't need it, but also strange, because it has 50 million weekly downloads.

If you have agreed to take over maintenance, or you have administrative capacity to make a change like this by some means, I wouldn't mind finishing the job.

[pkuczynski]

I can also help here if there is any interest and migrate to typescript