rollup_bundle cannot resolve imports (rules nodejs 2.0+) #2083
Comments
|
A few things missing in the minimal repro that were preventing rollup_bundle from resolving
Here is the full diff to get it building: |
|
This macro worked in pre 2.0.0 Do the same changes you mentioned also apply for this macro? |
|
@gregmagolan there is more information in #2086 which may be useful. While what you suggested works for simple cases, the problem is that it is a fundamental change in behaviour from what is documented, and inconsistent with Here's what the docs say: Note it refers to this as a "mapping", i.e. it is sugar. This means that the workspace mapping is simply an alternative way to refer to modules in the repository, absolutely - from the workspace root- rather than relatively. In the file
should refer to the same module and binding as
This means that the following should log import {MaterialModule} from '../shared/material/material.module';
import {MaterialModule as MaterialModule2} from 'examples_angular/src/shared/material/material.module';
console.log(MaterialModule===MaterialModule2);And with Not to mention that, for those of us who are using workspace references in a large monorepo extensively, it will be incredibly laborious to set up
|
|
here is a repro if it helps:
These are from src\shared\material\material.module.ts import {NgModule} from '@angular/core';
import {MatButtonModule} from '@angular/material/button';
import {MatCardModule} from '@angular/material/card';
import {MatFormFieldModule} from '@angular/material/form-field';
import {MatGridListModule} from '@angular/material/grid-list';
import {MatIconModule} from '@angular/material/icon';
import {MatInputModule} from '@angular/material/input';
import {MatListModule} from '@angular/material/list';
import {MatMenuModule} from '@angular/material/menu';
import {MatPaginatorModule} from '@angular/material/paginator';
import {MatRadioModule} from '@angular/material/radio';
import {MatSelectModule} from '@angular/material/select';
import {MatSidenavModule} from '@angular/material/sidenav';
import {MatTableModule} from '@angular/material/table';
import {MatToolbarModule} from '@angular/material/toolbar';
import {MatTooltipModule} from '@angular/material/tooltip';
import {msg} from "./repro/msg";
console.log(msg);
const matModules = [
MatButtonModule, MatCardModule, MatFormFieldModule, MatIconModule, MatInputModule, MatListModule,
MatToolbarModule, MatSidenavModule, MatRadioModule, MatSelectModule, MatGridListModule,
MatMenuModule, MatTableModule, MatPaginatorModule, MatTooltipModule
];
@NgModule({
imports: matModules,
exports: matModules,
})
export class MaterialModule {
}src\app\app.module.ts import {NgModule} from '@angular/core';
import {BrowserModule} from '@angular/platform-browser';
import {BrowserAnimationsModule} from '@angular/platform-browser/animations';
import {StoreModule} from '@ngrx/store';
import {MaterialModule} from '../shared/material/material.module';
import {MaterialModule as MaterialModule2} from 'examples_angular/src/shared/material/material.module';
import {AppRoutingModule} from './app-routing.module';
import {AppComponent} from './app.component';
import {HomeModule} from './home/home';
import {todoReducer} from './todos/reducers/reducers';
console.log(MaterialModule===MaterialModule2);
//...
This is because I have no idea how to use
Furthermore, it appears to me that the relative import
|
|
Hi @gregmagolan, Thanks for looking into this! I really appreciate it! That solution may work, however, I disagree with the approach. Here's my feedback:
Is the issue here that rollup_bundle expects js_library equivalent targets? Perhaps the real ask here is for a ts_rollup_bundle, which could configure rollup to find the es6 sources from ts_library deps and their transitive ts_library dependencies. Although on second thought, the mjs files are already in the bazel build sandbox, but rollup doesn't know how to resolve them. It still feels like an issue with the rollup_bundle rule and not with how the repository is configured (If rollup needs all imports declared as npm modules, that's an implementation detail that, IMHO, rollup_bundle should abstract away). |
|
This concern exactly matches my own thinking. Seems like we need to fix the contract / implementation of rollup_bundle? |
|
You could add a resolver plugin to rollup that knows how to find the bazel-out files, but the problem described here isn't really rollup-specific - anything downstream of a tree of ts_library rules may want to resolve the files. Seems like the right resolution is we can add back an optional flag so you can opt-out of this breaking change. |
|
What exactly was the breaking change that would get put back? |
|
It's hard to know for sure, but I think found a workaround to this problem. By adding this to all of my
if ctx.attr.module_name:
path = "/".join([p for p in [ctx.bin_dir.path, ctx.label.workspace_root, ctx.label.package] if p])
ts_providers["providers"].append(LinkablePackageInfo(
package_name = ctx.attr.module_name,
path = path,
files = ts_providers["typescript"]["es5_sources"],
_tslibrary = True,
))It's not great to have to hard-code the workspace name and package into every single Would this be a solution to the original issue? If so, perhaps there are some sane defaults we can add to Perhaps something like module_name = ctx.attr.module_name
if ctx.attr.default_module_name and not module_name:
module_name = "/".join([ctx.workspace_name, ctx.label.package])
if module_name:
path = "/".join([p for p in [ctx.bin_dir.path, ctx.label.workspace_root, ctx.label.package] if p])
ts_providers["providers"].append(LinkablePackageInfo(
package_name = ctx.attr.module_name,
path = path,
files = ts_providers["typescript"]["es5_sources"],
_tslibrary = True,
))My experiments also indicate that |
Basically the default |
|
Yes, that's what I've been doing locally and what the code above suggests |
|
Should be resolved by #2175 which adds back the ability for |
🐞 bug report
Affected Rule
The issue is caused by the rule: `rollup_bundle`Is this a regression?
Yes, the previous version in which this bug was not present was:
1.4.0; we upgraded from1.4.0to2.0.1, so the break occurred somewhere in that version range (likely with 2.0).Description
Our
rollup_bundlerules were working before upgrading to 2.0.1, but after upgrading, rollup can no longer find our imports, so the bundle generated only includes npm dependencies and the entry module. All other modules are assumed to be external dependencies and aren't included in the bundle.🔬 Minimal Reproduction
I have a reproduction here: https://github.com/CoopeyB/rollup-bazel-bug
This reproduction is configured to fail on an unresolved import.
There is also a very hacky workaround (commented out) in the
rollup.config.jsfile.🔥 Exception or Error
This error comes as a warning inside of rollup. However, if it's ignored, any dependent files outside of the initial entry of the bundle will be treated as external dependencies and not included in the bundle.
🌍 Your Environment
Operating System:
Output of
bazel version:Rules_nodejs version:
(Please check that you have matching versions between WORKSPACE file and
@bazel/*npm packages.)Anything else relevant?
This is the hacky workaround I found that manually resolves the .mjs files for the depended-on packages. However, it references bazel directories, and isn't portable:
The text was updated successfully, but these errors were encountered: