domino: SyntaxError: strict mode code may not contain 'with' statements

domino using with statements also results in build errors in Next JS 14.0.2 (also in 14.0.3): https://codesandbox.io/p/devbox/next-14-0-2-domino-build-error-bug-dylymw

domino is used as a dependency of turndown, which is itself a dependency of remirror, the module actually used in this sandbox app.

This specific bug is most likely an issue on how Next JS resolves the dependencies regarding JavaScript’s strict mode in the latest versions; but domino relying on with statements is the root of many potential breaking changes wherever they’re not expected, and that’s a fact that cannot be ignored.

Well, you could start by opening a bug on the angular project, as I’ve recommended. It doesn’t seem you’ve done that yet.

What’s the bug # on the angularjs project? This is not a domino bug, so commenting here isn’t being seen by anyone who knows angular well enough to fix the underlying issue.

I think that’s the bigger issue here, is that while this may not be “strictly” an issue with Domino, and can be fixed by a higher package int he chain, but which one is it? Webpack? Angular CLI? Which dependency is it even that uses Domino? Is it a sub sub sub child of higher package? Because for 99.99999999% of everything else, those are fine.

But at the bottom of the chain here, is Domino’s usage of a practice that is not recommended: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with

So while it sucks that webpack or whatever is accidentally carrying over a use strict into what is supposed to be a not-strict file (because there is no use sloppy), and I get it that that is clearly stated in the comments of the source file causing the issue, the other half here is that maybe this file should be updated to use a stricter standard anyways, or else packages relying on this dependency might want to look elsewhere and no one wants that.

The bigger problem is with packagers like webpack and gulp concatting 3rd party source code into a single source. Using sloppy mode is going to naturally cause problems when anything packaged as a higher priority above it slaps a use strict in there, which is going to be an overwhelming amount of the time (and there is no way to just “turn off” strict mode by stating a use sloppy somewhere)

–

I’m not trying to come off as harshly critical and I’m not even trying to tell you what to do or how to handle your project, I’m purely coming at this as a developer who installed a default version of a project that wouldn’t function because a single file way down the dependency chain wasn’t using strict mode and using non-strict compatible functionality and ends up bj0rking the whole thing because of it.

The question is for Webpack or Angular CLI, what CAN they do about it? Probably nothing. ngUniversal with Express however can probably figure out which dependency they need to update that doesn’t end up using Domino however, and just me personally I find that as well undesirable. Domino is clearly good at what it does. But this issue can be fixed at this level, whether it is or never does is entirely up to it’s collaborators, and that’s totally fair.

I just wanted to present my case and inform of why this is a problem now, will likely continue to be a problem going forward, and why you might want to look into making this file comply to stricter ECMA standards for maximum compatibility

On the same token, I empathize with the idea of “it’s not really our problem either” and that’s definitely well within your stance to take.

I just hope that maybe it isn’t is all and maybe a greater good can come out of this.

@cscott thanks for the reply. Any chance you know how to tell angular to not bundle this in strict mode? Or make a change to this package to not use with?

Or any other ideas you may have.

Try to avoid loading server modules in the browser module.

app.module.ts imports:

BrowserModule.withServerTransition({ appId: 'serverApp' }),
HttpClientModule,
TransferHttpCacheModule,
BrowserTransferStateModule,
AppRoutingModule,
TranslateModule.forRoot({
  loader: {
    provide: TranslateLoader,
    useFactory: TranslateBrowserLoaderFactory,
    deps: [HttpClient, TransferState]
  },
}),

app.server.module.ts imports:

AppModule,
ServerModule,
ServerTransferStateModule,
TranslateModule.forRoot({
  loader: {
    provide: TranslateLoader,
    useFactory: TranslateServerLoaderFactory,
    deps: [HttpClient, TransferState]
  }
})

For anyone landing on this thread: This seems to be an issue with how the dotnet command scaffolds the Angular project (and likely the fact that it uses a very outdated Angular CLI version). See the discussion in angular/angular#34970 for details.

Well, you could start by opening a bug on the angular project, as I’ve recommended. It doesn’t seem you’ve done that yet.

I truly do not believe Angular or even Angular CLI to be the issue here. I feel if it is to be escalated to a higher level package, it’s likely Webpack or ngUniversal. To which, yeah, i’ll open up an issue on ngUniversal next before Webpack. But I haven’t because I still believe this problem can be dealt with here, to resolve any further problems down the road when and if domino is included in similar toolchains

Try to avoid loading server modules in the browser module.

This was it for me. I had imported FlexLayoutServerModule in app.module.ts instead of app.server.module.ts.

@azuxx

You shouldn’t be using translateServerLoaderFactory in app.module. Use TranslateBrowserLoaderFactory instead.

it worked! I did also other fixings and here we are 🚀

app.server.module

@NgModule({
  imports: [
    AppModule,
    ServerModule,
    ServerTransferStateModule,
    TranslateModule.forRoot({
      loader: {
        provide: TranslateLoader,
        useFactory: translateServerLoaderFactory,
        deps: [TransferState]
      }
    }),
  ],
  bootstrap: [AppComponent],
})
export class AppServerModule {
}

app.module.ts

registerLocaleData(localeIt, 'it');

@NgModule({
  declarations: [
    AppComponent,
    HomeComponent,
    ForgotPasswordComponent,
    UserConfirmedComponent,
    SupportComponent,
    PrivacyPolicyComponent,
    TermsAndConditionsComponent
  ],
  imports: [
    BrowserModule.withServerTransition({appId: 'serverApp'}),
    TransferHttpCacheModule,
    // ngx-translate and the loader module
    HttpClientModule,
    TranslateModule.forRoot({
      loader: {
        provide: TranslateLoader,
        useFactory: translateBrowserLoaderFactory,
        deps: [HttpClient, TransferState]
      }
    }),
    AppRoutingModule,
    CoreModule,
    FormsModule,
    CommonModule,
    PdfViewerModule
  ],
  providers: [
    {provide: LOCALE_ID, useValue: 'it'}
  ],
  bootstrap: [AppComponent]
})
export class AppModule {
}

Thank you! Have a good one @bsumter