bazel-javascript
bazel-javascript copied to clipboard
fwouts
Non Relative Imports
This basically enables creating the node_modules directory in a more specific way. Instead of symlinking a node_modules folder directly it constructs a node_modules folder with all of the module folders symlinked. That allows for mixing in other modules that can be resolved using the typical node module resolution strategy.
I also added in the concept of a JsContext that wraps a rule context. I attempted to do this in a similar way to rules_go. The JsContext exposes a function js.library_info(js, attr) which exposes some common functionality for extracting common javascript attributes.
The beginnings of common sharable actions are in the internal/common/actions directory. Currently there is an action for running javascript with node, and an action for creating a source directory.
This change is 
@fwouts I think that this is ready for some review now. There is a lot of work around having some more shared generic js Providers in internal/common/context.bzl. I thought that it would make more sense to have this generic JsLibraryInfo provider that rule attributes get sorted into. Then some additional providers that could be extracted from the JsLibraryInfo + (some additional information). The JsModuleInfo has a lot of overlap with the JsLibraryInfo but is intended to be able to define modules without being 1:1 with a rule.
@fwouts I definitely don't mind putting the prettier, buildifier, and updated rules_nodejs in separate PRs. I probably don't have time to do so todya, so if you can get to it sooner much appriciated 🙇
@fwouts I definitely don't mind putting the prettier, buildifier, and updated rules_nodejs in separate PRs. I probably don't have time to do so todya, so if you can get to it sooner much appriciated 🙇
On it :)
BTW, there is module_name attribute in https://github.com/bazelbuild/rules_typescript for building libraries, so you can use it in absolute imports.
https://github.com/bazelbuild/rules_typescript/blob/10ff84f74bfa175ea86d49e090dcc38c5ca555b6/examples/some_library/BUILD.bazel#L23
https://github.com/bazelbuild/rules_typescript/blob/0a2d6be0a10bfc759d9255f70af5867f7aebf661/examples/bar.ts
Sorry I have been so quiet on this, ran out of time and needed to more forward but I'm hoping to wrap this one up soon.
@olegsmetanin my current understanding of the module_name attribute is that it is discovered by the module_mappings_runtime_aspect the rules_nodej implements the aspect as well but neither makes the aspect public. We could reimplement the aspect in these rules, but it seems like a strange pattern for everyone to implement an aspect that looks for module_name or module_root and assumes that is a non relative module. A better pattern would be to have a shared javascript provider as proposed in https://github.com/bazelbuild/rules_nodejs/issues/57. This PR creates some common providers that can at least be used internally to bazel-javascript.
@fwouts To unblock this I think all of the rules need to use js_context and used the shared providers defined in common:
I would also appreciate any comments you have around the architecture of these. They are modeled after the go providers:
My current thinking for what these represent for these rules:
JsLibraryInfo
Metadata that is extracted from the common js rule attributes by the js_library_info helper.
JsSourceInfo
Not sure if I actually need this one. But it is the information to create a transpilation source with the common create_source_dir action. It is intended to have information about file toplolgies and scripts that generate files in the transpilation source.
JsModuleInfo
Represents a javascript module, with the information about its transitive dependencies, the non-relative import name, and the path to the imported file/folder.
Apologies @enriched, I'm just coming back from two consecutive trips. I'll try and take a look in detail tomorrow with a fresh mind.
Happy new year @enriched! 🎉
I'd like to make sure we get this merged within the next month or two. Please let me know what I can do to help :)
@enriched Are you planning to continue work on this PR, or should we pick it up where you left off?