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 source-files and project structure #455

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

njlr
Copy link
Contributor

@njlr njlr commented Oct 4, 2024

In order to build Bazel rules for Fable, we need access to the F# source-files and target dependency graph. This information can be used to generate fsproj files that the Fable CLI tool can understand.

This PR exposes these things, but in a generic way, so that it can be used for multiple purposes.

I was able to build a proof-of-concept set of rules for Fable on top of this. However, before going further I would like feedback on these changes, since I hope to eventually have them merged into rules_dotnet.

Thanks!

Related: #315

@njlr njlr requested a review from purkhusid as a code owner October 4, 2024 18:18
@njlr njlr mentioned this pull request Oct 4, 2024
@purkhusid
Copy link
Collaborator

I'm not sure about the exact implementation you have for your Fable rules but I wonder why you need to couple the Fable rules with the rules_dotnet ones? AFAIK the Fable compiler only works with the source files so there is not need to compile a dll and then pass the results of that compilation to Fable.

If you can share the fable rules your are working on then I would maybe be able to see the usecase better?

@njlr
Copy link
Contributor Author

njlr commented Oct 6, 2024

I'm not sure about the exact implementation you have for your Fable rules but I wonder why you need to couple the Fable rules with the rules_dotnet ones? AFAIK the Fable compiler only works with the source files so there is not need to compile a dll and then pass the results of that compilation to Fable.

If you can share the fable rules your are working on then I would maybe be able to see the usecase better?

The idea is to be able to use rules_dotnet targets as inputs into rules_fable:

load("@aspect_rules_js//js:defs.bzl", "js_binary")
load("@npm//:defs.bzl", "npm_link_all_packages")
load("@npm//:webpack-cli/package_json.bzl", "bin")
load("@rules_dotnet//dotnet:defs.bzl", "fsharp_binary")
load("@rules_fable//fable:defs.bzl", "fable_bundle")

npm_link_all_packages(
  name = "node_modules",
)

fsharp_binary(
  name = "hello_world",
  srcs = [
    "Hello.fs",
  ],
  target_frameworks = [ "net6.0" ],
  deps = [
    "@paket.main//fsharp.core",
  ],
)

fable_bundle(
  name = "fable",
  target = ":hello_world",
)

bin.webpack_cli(
  name = "bundle",
  srcs = [
    ":fable",
  ],
  outs = [
    "dist/main.js",
  ],
  args = [
    "--mode",
    "production",
    "--entry",
    "./fable/Hello.fs.js",
  ],
  log_level = "debug",
)

js_binary(
  name = "app",
  entry_point = ":bundle",
)

This means that a user does not need to define the project structure twice.

@purkhusid
Copy link
Collaborator

I'm not sure I would want to add this as a public interface yet since I don't consider the providers public interfaces yet. This can be solved on the Fable rules side or on the end user side very easily by using a macro.

Sorry if that is a bummer but I'm trying to make the public API surface as small as possible to ease maintenance.

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

Successfully merging this pull request may close these issues.

2 participants