extern/nushell
1
0
Fork 1
mirror of https://github.com/nushell/nushell.git synced 2025-01-10 00:08:22 +01:00
Code Issues Packages Projects Releases Wiki Activity
3d5f853b03
nushell/crates/nuon/Cargo.toml

22 lines
744 B
TOML
Raw Normal View History

create `nuon` crate from `from nuon` and `to nuon` (#12553) # Description playing with the NUON format in Rust code in some plugins, we agreed with the team it was a great time to create a standalone NUON format to allow Rust devs to use this Nushell file format. > **Note** > this PR almost copy-pastes the code from `nu_commands/src/formats/from/nuon.rs` and `nu_commands/src/formats/to/nuon.rs` to `nuon/src/from.rs` and `nuon/src/to.rs`, with minor tweaks to make then standalone functions, e.g. remove the rest of the command implementations ### TODO - [x] add tests - [x] add documentation # User-Facing Changes devs will have access to a new crate, `nuon`, and two functions, `from_nuon` and `to_nuon` ```rust from_nuon( input: &str, span: Option<Span>, ) -> Result<Value, ShellError> ``` ```rust to_nuon( input: &Value, raw: bool, tabs: Option<usize>, indent: Option<usize>, span: Option<Span>, ) -> Result<String, ShellError> ``` # Tests + Formatting i've basically taken all the tests from `crates/nu-command/tests/format_conversions/nuon.rs` and converted them to use `from_nuon` and `to_nuon` instead of Nushell commands - i've created a `nuon_end_to_end` to run both conversions with an optional middle value to check that all is fine > **Note** > the `nuon::tests::read_code_should_fail_rather_than_panic` test does give different results locally and in the CI... > i've left it ignored with comments to help future us :) # After Submitting mention that in the release notes for sure!!
2024-04-19 13:54:16 +02:00
[package]
authors = ["The Nushell Project Developers"]
description = "Support for the NUON format."
repository = "https://github.com/nushell/nushell/tree/main/crates/nuon"
edition = "2021"
license = "MIT"
name = "nuon"
Bump to dev version 0.100.1 (#14328)
2024-11-14 10:04:39 +01:00
version = "0.100.1"
create `nuon` crate from `from nuon` and `to nuon` (#12553) # Description playing with the NUON format in Rust code in some plugins, we agreed with the team it was a great time to create a standalone NUON format to allow Rust devs to use this Nushell file format. > **Note** > this PR almost copy-pastes the code from `nu_commands/src/formats/from/nuon.rs` and `nu_commands/src/formats/to/nuon.rs` to `nuon/src/from.rs` and `nuon/src/to.rs`, with minor tweaks to make then standalone functions, e.g. remove the rest of the command implementations ### TODO - [x] add tests - [x] add documentation # User-Facing Changes devs will have access to a new crate, `nuon`, and two functions, `from_nuon` and `to_nuon` ```rust from_nuon( input: &str, span: Option<Span>, ) -> Result<Value, ShellError> ``` ```rust to_nuon( input: &Value, raw: bool, tabs: Option<usize>, indent: Option<usize>, span: Option<Span>, ) -> Result<String, ShellError> ``` # Tests + Formatting i've basically taken all the tests from `crates/nu-command/tests/format_conversions/nuon.rs` and converted them to use `from_nuon` and `to_nuon` instead of Nushell commands - i've created a `nuon_end_to_end` to run both conversions with an optional middle value to check that all is fine > **Note** > the `nuon::tests::read_code_should_fail_rather_than_panic` test does give different results locally and in the CI... > i've left it ignored with comments to help future us :) # After Submitting mention that in the release notes for sure!!
2024-04-19 13:54:16 +02:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
Bump to dev version 0.100.1 (#14328)
2024-11-14 10:04:39 +01:00
nu-parser = { path = "../nu-parser", version = "0.100.1" }
Start to Add WASM Support Again (#14418) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> The [nushell/demo](https://github.com/nushell/demo) project successfully demonstrated running Nushell in the browser using WASM. However, the current version of Nushell cannot be easily built for the `wasm32-unknown-unknown` target, the default for `wasm-bindgen`. This PR introduces initial support for the `wasm32-unknown-unknown` target by disabling OS-dependent features such as filesystem access, IO, and platform/system-specific functionality. This separation is achieved using a new `os` feature in the following crates: - `nu-cmd-lang` - `nu-command` - `nu-engine` - `nu-protocol` The `os` feature includes all functionality that interacts with an operating system. It is enabled by default, but can be disabled using `--no-default-features`. All crates that depend on these core crates now use `--no-default-features` to allow compilation for WASM. To demonstrate compatibility, the following script builds all crates expected to work with WASM. Direct user interaction, running external commands, working with plugins, and features requiring `openssl` are out of scope for now due to their complexity or reliance on C libraries, which are difficult to compile and link in a WASM environment. ```nushell [ # compatible crates "nu-cmd-base", "nu-cmd-extra", "nu-cmd-lang", "nu-color-config", "nu-command", "nu-derive-value", "nu-engine", "nu-glob", "nu-json", "nu-parser", "nu-path", "nu-pretty-hex", "nu-protocol", "nu-std", "nu-system", "nu-table", "nu-term-grid", "nu-utils", "nuon" ] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features} ``` ## Caveats This PR has a few caveats: 1. **`miette` and `terminal-size` Dependency Issue** `miette` depends on `terminal-size`, which uses `rustix` when the target is not Windows. However, `rustix` requires `std::os::unix`, which is unavailable in WASM. To address this, I opened a [PR](https://github.com/eminence/terminal-size/pull/68) for `terminal-size` to conditionally compile `rustix` only when the target is Unix. For now, the `Cargo.toml` includes patches to: - Use my forked version of `terminal-size`. - ~~Use an unreleased version of `miette` that depends on `terminal-size@0.4`.~~ These patches are temporary and can be removed once the upstream changes are merged and released. 2. **Test Output Adjustments** Due to the slight bump in the `miette` version, one test required adjustments to accommodate minor formatting changes in the error output, such as shifted newlines. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> This shouldn't break anything but allows using some crates for targeting `wasm32-unknown-unknown` to revive the demo page eventually. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` I did not add any extra tests, I just checked that compiling works, also when using the host target but unselecting the `os` feature. # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> ~~Breaking the wasm support can be easily done by adding some `use`s or by adding a new dependency, we should definitely add some CI that also at least builds against wasm to make sure that building for it keep working.~~ I added a job to build wasm. --------- Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-11-30 14:57:11 +01:00
nu-protocol = { path = "../nu-protocol", version = "0.100.1", default-features = false }
nu-engine = { path = "../nu-engine", version = "0.100.1", default-features = false }
nu-utils = { path = "../nu-utils", version = "0.100.1", default-features = false }
create `nuon` crate from `from nuon` and `to nuon` (#12553) # Description playing with the NUON format in Rust code in some plugins, we agreed with the team it was a great time to create a standalone NUON format to allow Rust devs to use this Nushell file format. > **Note** > this PR almost copy-pastes the code from `nu_commands/src/formats/from/nuon.rs` and `nu_commands/src/formats/to/nuon.rs` to `nuon/src/from.rs` and `nuon/src/to.rs`, with minor tweaks to make then standalone functions, e.g. remove the rest of the command implementations ### TODO - [x] add tests - [x] add documentation # User-Facing Changes devs will have access to a new crate, `nuon`, and two functions, `from_nuon` and `to_nuon` ```rust from_nuon( input: &str, span: Option<Span>, ) -> Result<Value, ShellError> ``` ```rust to_nuon( input: &Value, raw: bool, tabs: Option<usize>, indent: Option<usize>, span: Option<Span>, ) -> Result<String, ShellError> ``` # Tests + Formatting i've basically taken all the tests from `crates/nu-command/tests/format_conversions/nuon.rs` and converted them to use `from_nuon` and `to_nuon` instead of Nushell commands - i've created a `nuon_end_to_end` to run both conversions with an optional middle value to check that all is fine > **Note** > the `nuon::tests::read_code_should_fail_rather_than_panic` test does give different results locally and in the CI... > i've left it ignored with comments to help future us :) # After Submitting mention that in the release notes for sure!!
2024-04-19 13:54:16 +02:00
[dev-dependencies]
Setup global `cargo` lint configuration (#13691) # Description `cargo` somewhat recently gained the capability to store `lints` settings for the crate and workspace, that can override the defaults from `rustc` and `clippy` lints. This means we can enforce some lints without having to actively pass them to clippy via `cargo clippy -- -W ...`. So users just forking the repo have an easier time to follow similar requirements like our CI. ## Limitation An exception that remains is that those lints apply to both the primary code base and the tests. Thus we can't include e.g. `unwrap_used` without generating noise in the tests. Here the setup in the CI remains the most helpful. ## Included lints - Add `clippy::unchecked_duration_subtraction` (added by #12549) # User-Facing Changes Running `cargo clippy --workspace` should be closer to the CI. This has benefits for editor configured runs of clippy and saves you from having to use `toolkit` to be close to CI in more cases.
2024-08-28 23:37:17 +02:00
chrono = { workspace = true }
[lints]
Bump to version 0.99.0 (#14094) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2024-10-15 21:01:08 +02:00
workspace = true
Reference in New Issue Copy Permalink