Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose all CLI options to the npm library #173

Open
EcoFreshKase opened this issue Oct 6, 2024 · 6 comments
Open

Expose all CLI options to the npm library #173

EcoFreshKase opened this issue Oct 6, 2024 · 6 comments

Comments

@EcoFreshKase
Copy link
Contributor

Currently only the json flag can be set in the options for runFta. Adding more or all options could be helpful.

Adding options currently exposed to the CLI should be straightforward. For other config options I think #63 should be implemented before implementing this issue. Otherwise, I don't see a way of executing runFta without creating a fta.json for every run.

Additionally, I think changing the exported functions could be beneficial. Currently runFta always returns a string, either containing a formatted table or an array of AnalyzedFile as a string. Automatically converting the array would be helpful. Also, exposing two different functions could help create a clearer interface. Otherwise, every call of runFta would require a check or an explicit cast, even though the expected type is likely obvious from the context.

Other ideas are of course welcome!

@EcoFreshKase
Copy link
Contributor Author

I took a deeper look into the project code and WebAssembly. What is the reason for creating several different executables for the CLI instead of using WebAssembly?

There is even fta-wasm at the moment that exposes analyze_file_wasm. Perhaps fta-wasm could be used for the npm package? This could not only address the issue of creating a good interface for the npm package, but it would probably also significantly reduce the package size.

I quickly created a small test on my fork of the project.

@sgb-io
Copy link
Owner

sgb-io commented Oct 14, 2024

Hi @EcoFreshKase. In general, distributing separate binaries was a pratical way to ship the tool to multiple operating systems. It's generally designed to be used as a CLI tool.

That said, it also occurred to me that I could output a wasm build and allow it to run on the web, which works. However, I wasn't envisioning fta being used like a library.

I'm definitely open to perhaps another npm package coexisting that is a library version of fta -- at least, I think that's what you're getting at here?

@EcoFreshKase
Copy link
Contributor Author

@sgb-io yes, I would love to have fta as a library, because I want to use it to create a tool in the future.

How would you like to have this implement. Should we creat a npm package fta that has all the library functionality or should this be added to fta-cli? I think both approaches would be feasible. What do you think?

@sgb-io
Copy link
Owner

sgb-io commented Oct 15, 2024

@EcoFreshKase I would suggest that fta-cli stays as a CLI wrapper, and a new (non-CLI-named) npm package could be used for the library concept.

Note that you can't use fta as it's too short (NPM don't allow this for security reasons). It could be namespaced like @fta/core or @fta/metrics. Could also be a totally different name like fta-node.

If you can help propose what the library should contain/expose/do I'd be happy to get involved with this

@EcoFreshKase
Copy link
Contributor Author

@sgb-io I think it would make sense to group all the fta packages under a common namespace. For the library package I think @fta/core would be fine. In that case I would also propose to move fta-cli to @fta/cli and fta-wasm could be deprecated as this would propably be moved to @fta/core.
As far as I understand scoped packages at the moment, we would need to create a organization in npm. Otherwise, we wouldn't have the @fta prefix for the packages. But I didn't test it yet.

As for what should be contained in the library. I would suggest at least functions to analyze single files and whole projects and a possibility to get the metrics that are used internaly. Maybe even some util functionality to e.g. calculate the fta_score while providing all the metrics. I will try to find time in the coming days to create a whole scheme for what I think should be exposed.

@EcoFreshKase
Copy link
Contributor Author

@sgb-io sorry for the wait I was sick the last week.
I didn't want to create a whole docs and leave room for the implementation so I decided to just write a short sentence to everything I think should be contained in the library. This should cover everything I think or do you have any other ideas?

You said you wanted to get involved in this. How do you think should we split the work for this?

scheme

analyzeFile

should take a path to a file that should be analyzed by fta and options to configure the analysis.

analyzeProject

should take a path to the root of whole project that should be analyzed by fta and options to configure the analysis.

Options

Type that contains all configurations for the analysis

AnalyzedFile

fta results for one file

AnalyzedProject

fta results for a whole project

getScore

takes an AnalyzedFile without fta_score and returns the fta_score

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants