Read bs-dev-dependencies if --dev was passed.

[nojaf]

Fixes #7638, I believe.

I tested https://github.com/dsiu/rewatch-dev-deps-build-test locally.

I will add a test later, but please feel free to take a look and let me know if this logic is correct.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7650

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7650

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7650

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7650

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7650

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7650

commit: 5bf5fc2

[nojaf]

Okay, I discovered something interesting here.

The rules of https://rescript-lang.org/docs/manual/v12.0.0/build-configuration#bs-dependencies-bs-dev-dependencies are not respected in Rewatch right now.

I can have something like:

{
  "name": "dev-dep-sample",
  "sources": [
    {
      "dir": "src",
      "subdirs": true
    },
    {
    "dir": "test",
    "subdirs": true,
    "type": "dev"
  }],
  "package-specs": {
    "module": "esmodule",
    "in-source": true
  },
  "suffix": ".res.mjs",
  "bs-dependencies": [],
  "bs-dev-dependencies": [
    "@rescript/webapi"
  ],
  "bsc-flags": []
}

And src/Demo.res with:

open WebAPI

Console.log(Global.window)

where rescript --dev will build fine and rescript legacy build will hit:

bunx rescript legacy build                                                                                                     
>>>> Start compiling
Dependency on @rescript/webapi
rescript: [625/625] src/UIEventsAPI/WheelEvent-WebAPI.cmj
rescript: [603/603] install.stamp
Dependency Finished
rescript: [5/6] src/Demo.cmj
FAILED: src/Demo.cmj

  We've found a bug for you!
  /Users/nojaf/Projects/dev-dep-sample/src/Demo.res:1:6-11

  1 │ open WebAPI
  2 │ 
  3 │ Console.log(Global.window)

  The module or file WebAPI can't be found.
  - If it's a third-party dependency:
    - Did you add it to the "bs-dependencies" or "bs-dev-dependencies" in rescript.json?
  - Did you include the file's directory to the "sources" in rescript.json?
  

rescript: [6/6] test/Foo.cmj
FAILED: cannot make progress due to previous errors.
>>>> Finish compiling (exit: 1)

build_dev_deps is the value of --dev in

rescript/rewatch/src/build/compile.rs

Lines 351 to 364 in 556545d

	pub fn compiler_args(
	config: &config::Config,
	root_config: &config::Config,
	ast_path: &Path,
	file_path: &Path,
	is_interface: bool,
	has_interface: bool,
	project_root: &Path,
	workspace_root: &Option<PathBuf>,
	// if packages are known, we pass a reference here
	// this saves us a scan to find their paths
	packages: &Option<&AHashMap<String, packages::Package>>,
	build_dev_deps: bool,
	is_local_dep: bool,

and does not reflect whether the source file is type: dev and can thus use bs-dev-dependencies.

[nojaf]

Hmm, this is proving to be somewhat difficult.
For build, we have the package information, and we could do a lookup if the file is type:dev or not. We can store this when we call extend_with_children.

However, for compiler-args, we don't construct this information and this is None:

rescript/rewatch/src/build/compile.rs

Lines 360 to 362 in 0c36cb5

	// if packages are known, we pass a reference here
	// this saves us a scan to find their paths
	packages: &Option<&AHashMap<String, packages::Package>>,

[jfrolich]

This is very expensive, this would scan all the files in the package. I think it would be better to see if the current file matches any of the dev paths.

[jfrolich]

The idea of this command that it's a very low-latency for the editor tooling to know the compile arguments. Reading all the files would create a lot of overhead.

[jfrolich]

this is a semi slow lookup, if we compile a file we usually construct it from the module struct, that module struct has a field if it's a local dep. Looking up the module again from the package is unneeded, we can just pass the module attribute to this function instead.

[jfrolich]

I don't think it's relevant to put here, I would put it on the Module struct

[nojaf]

We would still need it here if we want to put it in Module struct.
packages::parse_packages will loop over all the source_files and by that time, we no longer know what "type" they had.

[jfrolich]

we don't have the explicit command to build the dev deps anymore?

[nojaf]

We do, that is part of BuildArgs.
Here this is about the compile-args which the tooling calls to figure out the arguments. Tooling does not know if a file is type:dev or not.

[nojaf]

@jfrolich I added some code to traverse the rescript.json in case of compiler-arguments command.

I'm unsure how to proceed with the Module suggestion you have. Could use a technical pointer there.