NUKnightLab / NUKnightLab/TimelineJS3

The `package.json` is missing the `main` or `exports` fields

Open
#889 0 comments 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
3.2k
Forks
645
PR merge metrics
No merged PRs in 30d

Description

Issue

The package.json doesn't filter what files should be packaged and sent the NPM. Therefore, all the source code with .less files is being distributed.

Also, the entry point of the package is not specified using main, module, or exports. That way, it's confusing for the bundlers what should be used and usually they start picking the files from the src:
https://github.com/NUKnightLab/TimelineJS3/blob/c5948d41fd333a1d292ec1c497c38e52ef793013/index.js#L1

So it requires to double-transpile the package in the consuming app and they don't benefit from the transpilation done before publishing anyway 😢

Suggested changes

  1. Limit the distributed code only to the dist folder. That will significantly reduce the size of the package.
  2. Specify an entry point explicitly and it should point to the transpiled files in the dist.

Smth like this[^1]:

{
  "name": "@knight-lab/timelinejs",
  "version": "4.0.0",
  "type": "module",
  "files": [
    "dist"
  ],
  "exports": {
    ".": {
      "import": "./dist/index.js"
    }
  },
  "main": "./dist/index.js",
  ...  
Config breakdown

Node has already come up with the following package.json properties that allow to limit what will get published to NPM:

  • files - "an array of file patterns that describes the entries to be included when your package is installed as a dependency"
  • main - "a module ID that is the primary entry point to your program. That is, if your package is named foo, a user installs it, and then does require("foo")"
  • types - Set the types property to point to your bundled declaration file.
  • exports - "defining the entry points of a package. An alternative to the "main" that can support defining "subpath exports" and "conditional exports".

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting package.json, the existing dist folder, and the referenced index.js entry point. Check the package contents that would be published and how the current build output is consumed; done means only the intended dist files are distributed and package imports resolve to the transpiled entry point.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
build-system
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.