Want to use oxc_linter as crate

[ityuany]

I really like the oxc series of tools.

We have a scenario where oxc_linter is intended to be used directly as rust crate. Could you please send a package to support it

[Boshen]

That's extended maintenance burden for us. Can you use git = "https://github.com/oxc-project/oxc.git" first and send PRs to make it accessible before we release it crates.io?

[ityuany]

@Boshen

This will cause me to download an additional napi, once

[Boshen]

@Boshen

This will cause me to download an additional napi, once

I removed it in #7510, but version will still conflict ...

[ityuany]

Does this seem to have new requirements for my rust version?

[ityuany]

@Boshen

Sorry, I'm a rust novice and used to work more on node and the front end. I don't quite understand why releasing oxc to Crate.io would add an extra maintenance burden, my understanding he should just be more than a publish action, perhaps I exist in the knowledge of the blind, can answer it. In addition, it may be important to me that OXC be released to Crate.io so I can use it directly, and I'd still like to support it if possible. Thank you very much

[nrayburn-tech]

Releasing as a crate means that it now needs to be maintained and supported for clients to use. This includes things like APIs that make sense for clients (structs, methods), changelog, etc. This maintenance is the extra burden. The action of just publishing it is unlikely to be an issue.

[camc314]

Does this seem to have new requirements for my rust version?

Looks like this was stablized in 1.81.0 . i would try updating your rust version to solve the problem

rust-lang/rust#120924

[ityuany]

Releasing as a crate means that it now needs to be maintained and supported for clients to use. This includes things like APIs that make sense for clients (structs, methods), changelog, etc. This maintenance is the extra burden. The action of just publishing it is unlikely to be an issue.

I understand, I think what you said makes a lot of sense, thank you for your response. Maybe I should try to understand the overall code design of oxc more deeply, and then try to take on this part of the work actively?

[nrayburn-tech]

I believe that is what Boshen was suggesting. My understanding of it is below, although you should confirm with him.

Use the library with the GitHub URL for now. As you find issues, submit PRs to make improvements. Once things have been improved in a way that it is better to consume as a library and Boshen is comfortable with it not adding a significant maintenance burden, publishing as a crate becomes a much more realistic option (publishing as a crate isn’t guaranteed at this point, but it also isn’t completely off the table).

[ityuany]

I tried to install it using the git address and found the private module

[Boshen]

I tried to install it using the git address and found the private module

Can you PR?

[ityuany]

I think maybe I found the right way to use it, but there seems to be some compatibility issues。

Excuse me, I am a novice, I don't know how to fix it.

use std::{path::Path, rc::Rc, sync::Arc};

use oxc_allocator::Allocator;
use oxc_linter::{
  AllowWarnDeny, FixKind, LintFilter, LintFilterKind, LinterBuilder,
  RuleCategory,
};
use oxc_parser::Parser;
use oxc_semantic::SemanticBuilder;
use oxc_span::SourceType;

fn main() -> std::io::Result<()> {
  let path = Path::new("hello.js");
  let source_text = std::fs::read_to_string(path)?;

  let allocator = Allocator::default();
  let source_type = SourceType::from_path(path).unwrap();
  let ret = Parser::new(&allocator, &source_text, source_type).parse();

  let semantic_builder = SemanticBuilder::new()
    .with_cfg(true)
    .with_scope_tree_child_ids(true);

  let semantic_ret = semantic_builder.build(&ret.program);
  let semantic = Rc::new(semantic_ret.semantic);
  let module_record = Arc::new(oxc_linter::ModuleRecord::new(
    path,
    &ret.module_record,
    semantic,
  ));

  let linter = LinterBuilder::default()
    .with_filters(vec![
      LintFilter::new(AllowWarnDeny::Warn, "no-debugger").unwrap(),
      LintFilter::new(AllowWarnDeny::Deny, "no-console").unwrap(),
      LintFilter::new(AllowWarnDeny::Warn, "no-commonjs").unwrap(),
      LintFilter::new(AllowWarnDeny::Warn, RuleCategory::Correctness).unwrap(),
    ])
    .with_fix(FixKind::None)
    .build();

  let diagnostics = linter.run(path, semantic, module_record);

  for message in diagnostics {
    println!("{:?}", message.error);
  }

  Ok(())
}

[ityuany]

[Boshen]

@ityuany use 0.39.0 for now, there's a problem with 0.40.1.

And this is why I don't want to release it as a crate, this process is already burdening.

[ityuany]

I've found that this works fine, but it creates a confusion for my team members that all tags use oxlint_v0.15.0, which makes the versions of oxc_ast, oxc_span, ... This will make the versions of oxc_ast, oxc_span, ... less intuitive and clear. But at least this way he is working. I'm going to use it this way for now, and wait for the next dear Boshen to solve the conflict problem better!