Skip to content

Fix JavaScript lint errors #15831

Open

Description

@stdlib-bot

JavaScript Linting Failures

Linting failures were detected in the automated JavaScript lint workflow run.

Workflow Details

Error Details

make[1]: Entering directory '/home/runner/work/stdlib/stdlib'

Linting file: lib/node_modules/@stdlib/math/base/special/sinpi/examples/index.js
sin( π * -53.7289 ) = 0.7525
sin( π * 10.0604 ) = 0.1886
sin( π * -75.0707 ) = 0.2202
sin( π * 25.6021 ) = -0.9490
sin( π * -57.8263 ) = 0.5189
sin( π * 36.2336 ) = 0.6698
sin( π * 16.9863 ) = 0.0431
sin( π * -29.8915 ) = 0.3342
sin( π * 16.8809 ) = 0.3655
sin( π * 3.9153 ) = -0.2630
sin( π * 61.2014 ) = -0.5913
sin( π * 83.5369 ) = -0.9933
sin( π * -72.1171 ) = -0.3597
sin( π * -59.0313 ) = 0.0982
sin( π * 92.9175 ) = 0.2562
sin( π * 21.1339 ) = -0.4084
sin( π * -90.9204 ) = -0.2475
sin( π * -14.9770 ) = -0.0723
sin( π * -99.4096 ) = 0.9599
sin( π * -68.5620 ) = -0.9811
sin( π * 27.9315 ) = -0.2137
sin( π * 75.7515 ) = -0.7038
sin( π * 63.3516 ) = -0.8933
sin( π * -61.9552 ) = 0.1401
sin( π * -83.3888 ) = 0.9396
sin( π * 51.9061 ) = -0.2908
sin( π * -84.0109 ) = -0.0344
sin( π * 68.7519 ) = 0.7028
sin( π * -50.6690 ) = -0.8623
sin( π * -55.1890 ) = 0.5594
sin( π * 69.4866 ) = -0.9991
sin( π * 22.6595 ) = 0.8771
sin( π * 47.6803 ) = -0.8438
sin( π * -5.0149 ) = 0.0467
sin( π * -99.2026 ) = 0.5943
sin( π * 80.0739 ) = 0.2300
sin( π * 88.2946 ) = 0.7989
sin( π * 84.4426 ) = 0.9838
sin( π * 56.3179 ) = 0.8408
sin( π * 31.3788 ) = -0.9284
sin( π * -47.8045 ) = 0.5762
sin( π * 4.0103 ) = 0.0324
sin( π * 63.0885 ) = -0.2745
sin( π * 18.7167 ) = 0.7771
sin( π * 49.0599 ) = -0.1870
sin( π * -1.8054 ) = 0.5739
sin( π * 73.9294 ) = -0.2199
sin( π * 63.0864 ) = -0.2680
sin( π * -39.7955 ) = 0.5992
sin( π * -88.2827 ) = -0.7758
sin( π * -37.3266 ) = 0.8553
sin( π * -15.6779 ) = 0.8479
sin( π * -79.9851 ) = 0.0467
sin( π * 28.3493 ) = 0.8901
sin( π * -91.9504 ) = 0.1551
sin( π * -80.1776 ) = -0.5295
sin( π * 4.3556 ) = 0.8989
sin( π * 51.1397 ) = -0.4249
sin( π * 81.8452 ) = -0.4674
sin( π * 38.4304 ) = 0.9762
sin( π * 44.2503 ) = 0.7078
sin( π * -48.9646 ) = -0.1109
sin( π * -10.4099 ) = -0.9602
sin( π * -6.5809 ) = -0.9679
sin( π * 74.8014 ) = 0.5843
sin( π * 59.9207 ) = -0.2464
sin( π * 54.6096 ) = 0.9414
sin( π * 78.8821 ) = 0.3620
sin( π * 8.6834 ) = 0.8385
sin( π * 58.6047 ) = 0.9464
sin( π * 56.2884 ) = 0.7871
sin( π * -29.1662 ) = 0.4988
sin( π * 74.5106 ) = 0.9994
sin( π * -90.0247 ) = -0.0775
sin( π * 98.0539 ) = 0.1686
sin( π * 46.7066 ) = 0.7967
sin( π * -13.9955 ) = 0.0142
sin( π * -1.8321 ) = 0.5034
sin( π * -92.3157 ) = -0.8370
sin( π * 7.8289 ) = -0.5121
sin( π * -57.2872 ) = 0.7847
sin( π * 89.0168 ) = -0.0528
sin( π * 98.2196 ) = 0.6366
sin( π * 29.7628 ) = -0.6781
sin( π * 6.3056 ) = 0.8192
sin( π * 54.1102 ) = 0.3393
sin( π * -80.3008 ) = -0.8106
sin( π * -92.3212 ) = -0.8463
sin( π * -55.5848 ) = 0.9647
sin( π * -57.8462 ) = 0.4645
sin( π * 83.7927 ) = -0.6062
sin( π * 76.4838 ) = 0.9987
sin( π * 11.0504 ) = -0.1577
sin( π * 6.8545 ) = 0.4413
sin( π * 88.6655 ) = 0.8678
sin( π * 31.0418 ) = -0.1310
sin( π * 46.0092 ) = 0.0290
sin( π * -47.0303 ) = 0.0951
sin( π * 53.4658 ) = -0.9942
sin( π * 3.5861 ) = -0.9636

Linting file: lib/node_modules/@stdlib/constants/float32/examples/index.js

Linting file: lib/node_modules/@stdlib/utils/reject-arguments/examples/index.js

Linting file: lib/node_modules/@stdlib/stats/base/ndarray/mskmidrange/examples/index.js

Linting file: lib/node_modules/@stdlib/assert/is-primitive/examples/index.js

/home/runner/work/stdlib/stdlib/lib/node_modules/@stdlib/assert/is-primitive/examples/index.js
57:27  error  Using the `new Array()` constructor is not allowed; use an array literal with push instead  stdlib/no-new-array

✖ 1 problem (1 error, 0 warnings)

Linting failed.

Linting file: lib/node_modules/@stdlib/stats/base/dists/degenerate/mode/examples/index.js
μ: 0.1202, mode(X;μ): 0.1202
μ: 0.0369, mode(X;μ): 0.0369
μ: 0.0648, mode(X;μ): 0.0648
μ: 0.8993, mode(X;μ): 0.8993
μ: 0.3131, mode(X;μ): 0.3131
μ: 0.6684, mode(X;μ): 0.6684
μ: 0.0775, mode(X;μ): 0.0775
μ: 0.3325, mode(X;μ): 0.3325
μ: 0.6323, mode(X;μ): 0.6323
μ: 0.8775, mode(X;μ): 0.8775

Linting file: lib/node_modules/@stdlib/constants/float64/ln-sqrt-two-pi/examples/index.js

Linting file: lib/node_modules/@stdlib/console/examples/index.js

Linting file: lib/node_modules/@stdlib/datasets/img-locomotion-nude-male/examples/index.js
make[1]: *** [/home/runner/work/stdlib/stdlib/tools/make/lib/lint/javascript/eslint.mk:261: eslint-files] Error 1
make[1]: Leaving directory '/home/runner/work/stdlib/stdlib'
make: *** [/home/runner/work/stdlib/stdlib/tools/make/lib/lint/javascript/Makefile:158: lint-javascript-files] Error 2

Pull Request Instructions

  • Please use the following PR title format:
    "chore: fix JavaScript lint errors (issue #<ISSUE_NUMBER>)".
  • Reference this issue in the "Related Issues" section of the PR body as "resolves #<ISSUE_NUMBER>".

Activity

  1. stdlib-bot commented on Oct 3, 2026

    @stdlib-bot
    ContributorAuthor

    👋 Important: PLEASE READ 👋

    This issue has been labeled as a good first issue and is available for anyone to work on.

    If this is your first time contributing to an open source project, some aspects of the development process may seem unusual, arcane, or some combination of both.

    1. You cannot "claim" issues. People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
    2. We have a very high bar for contributions. We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.

    Before working on this issue and opening a pull request, please read the project's contributing guidelines. These guidelines and the associated development guide provide important information, including links to stdlib's Code of Conduct, license policy, and steps for setting up your local development environment.

    To reiterate, we strongly encourage you to refer to our contributing guides before beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.

    Setting up your local development environment is a critical first step, as doing so ensures that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. If you would prefer to avoid manual setup, we provide pre-configured development containers for use locally or in GitHub Codespaces.

    We place a high value on consistency throughout the stdlib codebase. We encourage you to closely examine other packages in stdlib and attempt to emulate the practices and conventions found therein.

    • If you are attempting to contribute a new package, sometimes the best approach is to simply copy the contents of an existing package and then modify the minimum amount necessary to implement the feature (e.g., changing descriptions, parameter names, and implementation).
    • If you are contributing tests, find a package implementing a similar feature and emulate the tests of that package.
    • If you are updating documentation, examine several similar packages and emulate the content, style, and prose of those packages.

    In short, the more effort you put in to ensure that your contribution looks and feels like stdlib—including variables names, bracket spacing, line breaks, etc—the more likely that your contribution will be reviewed and ultimately accepted. We encourage you to closely study the codebase before beginning work on this issue.

    ✨ Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions. ✨

  2. lb1192176991-lab commented on Oct 3, 2026

    @lb1192176991-lab

    Submitted PR #15832 for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Good First IssueA good first issue for new contributors!

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions