build: add wasm configurations - #13771
Conversation
---
type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes.
report:
- task: lint_filenames
status: passed
- task: lint_editorconfig
status: passed
- task: lint_markdown_pkg_readmes
status: na
- task: lint_markdown_docs
status: na
- task: lint_markdown
status: na
- task: lint_package_json
status: passed
- task: lint_repl_help
status: na
- task: lint_javascript_src
status: na
- task: lint_javascript_cli
status: na
- task: lint_javascript_examples
status: na
- task: lint_javascript_tests
status: na
- task: lint_javascript_benchmarks
status: na
- task: lint_python
status: na
- task: lint_r
status: na
- task: lint_c_src
status: na
- task: lint_c_examples
status: na
- task: lint_c_benchmarks
status: na
- task: lint_c_tests_fixtures
status: na
- task: lint_shell
status: na
- task: lint_typescript_declarations
status: passed
- task: lint_typescript_tests
status: na
- task: lint_license_headers
status: passed
---
| "__stdlib__": { | ||
| "wasm": false | ||
| } | ||
| "__stdlib__": {} |
There was a problem hiding this comment.
Should complex packages in blas/ext/base also include this package.json change?
There was a problem hiding this comment.
This change is fine, IIRC. But also leaving as is is fine, as well.
There was a problem hiding this comment.
This field is more important for when a WebAssembly implementation IS present "wasm": true, as this allows us to search for packages with wasm implementations based on package meta data.
There was a time when wasm implementations were not separate packages and explicitly setting the wasm field was a means to avoid needing to check for source files. We've since evolved since then. So, in short, this change is fine, but the status quo is also harmless.
| }, | ||
| { | ||
| "task": "examples", | ||
| "task": "build", |
There was a problem hiding this comment.
I guess if I can understand why we have some variations of this in the blas/ext/base packages, or why we have these in our implementations, it would give me a better picture of what to consider when making this kind of change, deciding whether to include it in future implementations, and determining which implementations should include it.
cc: @kgryte
There was a problem hiding this comment.
The changes in this PR were only made because I noticed this inconsistency in the existing packages, including the ones I recently added.
There was a problem hiding this comment.
In short, we incrementally updated the manifest.json files as we added WebAssembly implementations. It is fine to go ahead and preemptively add the wasm configurations. So, what you are seeing wrt variations stems from the in-progress wasm work (see the blas/ext/base/wasm namespace for reference).
There was a problem hiding this comment.
See https://github.com/stdlib-js/stdlib/pull/5630/changes for an example of what I am referring to by incremental migration.
Coverage Report
The above coverage report was generated for the changes in this PR. |
blas/ext/base manifest
Resolves None
Description
This pull request:
blas/ext/basemanifestRelated Issues
This pull request has the following related issues:
blas/ext/base/swxsymetr-issue-tracker#900Questions
No.
Other
No.
Checklist
AI Assistance
If you answered "yes" above, how did you use AI assistance?
Disclosure
Used Cursor+VS Code code-generation tools to help assist with the feature.
@stdlib-js/reviewers